Over the past twenty years, the democratization of cryptographic technology has brought us the potential for an unprecedented level of privacy, giving the common man the ability to browse documents, have conversations, and now, with Bitcoin, send money to people around the world without even the most powerful corporations and government agencies being able to get in the way, but actual adoption of these technologies has been slow. It was once thought that PGP, the encryption tool created by Phil Zimmermann in 1991, was undoubtedly going to become standard in all email communications within years, but it is now 2012, and most email communication is still done in the clear, with providers like Gmail having the ability to read everything that their users write.
Some argue that the reason why encryption has not been implemented into email protocols is profit, as Google would have no way to earn advertising revenue from their service if they could not scan users’ emails for keywords, and others cite general apathy, quoting Mark Zuckerberg’s famous comment that privacy is no longer a “social norm”, but there is also a more fundamental issue at play: network effects. If you were to create an encrypted email right now with PGP and send it to a friend, they would have a difficult time figuring out what to do with it. For the encryption to be worth anything, your friend would need to have a decryption key under his control, whether that’s a public key or a symmetric key that the two of you had agreed upon earlier, and convincing other people who are not as technologically inclined to use such keys can be a challenge. There are isolated communities in which encryption is used, whether out of ideology or out of necessity – Bitcoin itself has a considerable number of pseudonymous businessmen and developers who rely on PGP to maintain their online identities. However, by and large, this is not the case. If encrypted email was popular enough in the world at large, the average person would have an incentive to set up a public key, but the fact that it is currently a niche technology means that they will not, perpetuating a catch-22 situation which requires a large portion of society to somehow coordinate to escape.
Enter Bitcoin. Although we tend to think of Bitcoin as a system designed specifically to send financial transactions, recent developments have shown that much more can be done with its cryptographic primitives. As early as 2011, people were using the lower digits of Bitcoin transactions as a way of encoding messages in the blockchain; one of the Bitcoinica thieves famously used the mechanism to distribute the message “expect mass leak soon“. Beyond the fact that this message will remain in the blockchain forever, an advantage of this technique is that the message is also authenticated; since sending a message in this way requires you to control the address that the transactions are sent from. If it is already known that you control a given address, then clearly you must have sent the transactions as well.
However, this ad-hoc messaging system is clumsy and inefficient, and the concept of Bitcoin messaging has seen two iterations since then. The first is Blockchain.info’s concept of blockchain notes. The implementation is simple. The sender sends a non-standard transaction with two outputs. One of the outputs sends a very small amount of money to the receiver, while the other does not go to anyone at all. Instead, in the output field of the transaction is the message itself. If interpreted as a script, the message is impossible to fulfill, so that output will simply sit there in the blockchain, never to be spent. However, this approach met with strong opposition from Bitcoin developers for polluting the blockchain. Gavin Andresen wrote :”Yes, please don’t create lots of unspendable scriptPubKeys. There are more prunable ways of embedding messages into transactions. And there are even better ways of associating messages with transactions, so only people involved with the transaction can read the message (if that’s desired). In other words, lets figure out how to do this the right way.” The blockchain note system was soon converted into a proprietary feature of blockchain.info’s wallet.
The other advancement was message signatures. In version 0.6, the Satoshi client added a feature which allows the client to use the same algorithm used in Bitcoin to sign transactions to sign any other message as well. Using the exact same cryptographic techniques that allow miners to verify that the owner of an address authorized a transaction sending money from that address, anyone can verify (using a tool also present in the Satoshi client since version 0.7) that a message signed with a given address was signed by the address’ owner. Electrum and brainwallet.org also support this standard for both signing and verification. This mechanism solves the authentication problem, and it does not pollute the blockchain, but it has a problem of its own: there is no built-in transmission mechanism. Thus, just like PGP, the only way to send a signed message is to create a format (called ASCII armoring in PGP) that combines the message and the signature into a block, and then paste the block all together as a message. Essentially, this creates a PGP clone based on Bitcoin’s elliptic curve cryptography, with all of its advantages and disadvantages.
BitMessage, however, solves both of these issues. Rather than going through Bitcoin’s peer-to-peer network, BitMessage creates a peer-to-peer network of its own with properties specifically designed for sending messages. As the whitepaper describes it, “objects are broadcast throughout a Bitmessage stream. We propose that nodes store all objects for two days and then delete them. Nodes joining the network request a list of objects from their peer and download the objects that they do not have. Thus they will receive all messages bound for them that were broadcast during the last two days.” “Objects” are the basic unit of the network’s operation, and are replicated throughout the network. To limit the creation of objects and avoid spam, making an object requires solving a proof-of-work computation, which takes about four minutes on an average computer – in short, a replica of Adam Back’s HashCash anti-spam scheme first proposed in 1997.
Sending a message is a four-step back-and-forth process. First, the sender creates an object asking for the receiver’s public key. Second, when the receiver receives this object, he creates a reply object sending the key back. Third, the sender creates an object containing the actual message encrypted with the receiver’s public key, and, finally, the receiver receives the object and sends an acknowledgement message. The main message can be much longer than the short text string that can fit inside a series of transactions or an output slot; the whitepaper explicitly mentions that the scheme “would allow an individual or organization to anonymously publish content.” If both the sender and receiver are online, the process can happen within seconds, but otherwise they merely need to be online within a two day timespan of each other four times (really three times, as the acknowledgement is not crucial to sending the message) for the transmission to take place. Once two users are aware of each other’s public keys, the first and second steps do not need to be repeated, making the process even easier. Identities on BitMessage are referred to by addresses like “BM-2nijaB5b1C6HESgdqFMoMzWqNchA9w84Xmv”, which are formed from public keys in a similar way to Bitcoin addresses.
However, although the fundamental ideas behind BitMessage are both innovative and sound, BitMessage as it is is not without its flaws. One blogger wrote a scathing review of BitMessage’s security, pointing out that it made a number of elementary mistakes in implementing its encryption algorithms. First, it uses RSA on the message directly rather than using it to generate a one-time key which is then used to encrypt the message, a basic modification which both drastically increases speed and prevents many attacks based on specifically constructing blocks to exploit the algorithm’s mathematical properties. Second, it independently encrypts each block rather than using an encryption mode like cipher block chaining which makes the contents of the encrypted blocks dependent on each other. This means that an attacker can rearrange the blocks of an encrypted message, which it will appear to the receiver as a valid message, as if the original sender intended for the message’s blocks to come in the attacker’s chosen order. Finally, the encryption algorithm does not include an authentication layer, making other kinds of attacks possible. However, BitMessage developer Jon Warren is aware of these flaws, and is working hard on creating another version of the protocol that fixes these issues.
Another one major flaw that BitMessage arguably has is that it is not compatible with Bitcoin itself. Unlike Bitcoin, which uses elliptic curve cryptography to secure transactions and now messages, BitMessage uses 2048-bit RSA. RSA is in many ways more difficult than ECC to work with. It requires much longer key lengths to achieve the same level of security (eg. 3072-bit RSA is about equivalent to Bitcoin’s 256 bit ECC), and because RSA keys must have a special property to be valid (namely, being a product of two large prime numbers) they take a comparatively long time to generate, and there is no standardized algorithm for generating keypairs deterministically from a seed. But the main advantage of a system compatible with Bitcoin is not even this. Rather, it’s the fact that if a similar system were to be designed that could interoperate with Bitcoin’s private and public keys, it would be able to take advantage of the infrastructure that exists around Bitcoin already. It would be able to use the private and public keys that are already sitting in hundreds of thousands of Bitcoin users’ wallets, and would also be able to skip the public key retrieval step, as public keys can easily be recovered from the blockchain.
Furthermore, it would be possible to merge the message transmission and payment features into one, creating a sort of unified payment and social network service in a decentralized way. If Alice wanted to send 10 BTC to Bob, she would not need to ask Bob to give her an address as she does now; rather, she would be able to simply send money to the address that she already uses to send Bob her private communications. The scheme can easily be augmented to preserve privacy. One interesting property of elliptic curve cryptography is the existence of an operation called point multiplication, which allows a public key to be multiplied by a value to create a new public key, from which Alice can generate another address, and then Bob can multiply his private key by the same constant to get a new private key that corresponds to the public key and address that Alice just created. This is the key insight behind a concept known as the deterministic wallet, already implemented in Electrum, and it can be applied to create one-time keys for messaging and payment as well.
Fortunately, the BitMessage protocol is designed to be upgradeable, and the next version of the protocol may end up both solving the security problems and introducing Bitcoin compatibility by simply switching BitMessage’s cryptography to the same elliptic curve system used by Bitcoin. If BitMessage continues to develop and grow, or even if another, similar technology takes its place, what it can offer is a decentralized, cryptographically secure platform that can form the basis for its users’ entire online lives. One can potentially extend the system to add on a web of trust, a systematic way of declaring friends and business relationships, personal webpages, and it already supports a Twitter-like mechanism of subscribing to individuals and receiving a feed from them. In ten years’ time, there is a chance that Bitcoin will prove to be much more than just a decentralized digital currency; it may be the start of an effort to redevelop much of the internet from scratch – and this time done right.
http://bitcoinmagazine.com/bitmessage-a-model-for-a-new-web-2-0/
