Bitmessage: A Peer‐to‐Peer Message Authentication and Delivery SystemSee more here.... Survival Monkey
November 27, 2012
"Abstract. We propose a system that allows users to securely send and receive messages, and subscribe to broadcast messages, using a trustless decentralized peer‐to‐peer protocol. Users need not exchange any data beyond a relatively short (around 36 character) address to ensure security and they need not have any concept of public or private keys to use the system. It is also designed to mask non‐content data, like the sender and receiver of messages, from those not involved in the communication."
Email is ubiquitous but not secure. The ability to send encrypted messages is necessary but current solutions are too difficult for people to use: users must exchange both an email address and an encryption key through a trusted channel (like in person or by phone). Even users who do know how to use tools like PGP/GPG usually do not put forth the effort to do so unless they are particularly concerned about the message content. Novice users have a difficult time learning how to use the software because the relationship between public and private key pairs, and their uses, are foreign concepts. Even if users do manage to use PGP/GPG for communications, encryption alone does not mask the sender and receiver of messages. Government agencies in several countries are collecting call‐detail records for all individuals and storing them in large databases for use in social‐network‐analysis . There would be nothing stopping them from collecting the content of phone calls and messages also, and indeed, officials have told the New York Times that the United States’ National Security Agency has engaged in “overcollection” .
Hiding one’s identity is difficult. Even if throw‐away email addresses are used, users must connect to an email server to send and retrieve messages, revealing their IP address. If they use Tor to connect to a web server, they depend on the X.509 system for security. This system enables HTTPS. X.509 certificate authorities have suffered hacks in recent years including one incident where Iran used a fraudulent but mathematically valid certificate that was signed with the key of a hacked certificate authority (DigiNotar) to conduct a man‐in‐the‐middle attack against its citizens who were using Google services like Gmail .
As the security of HTTPS is only as strong as the least trustworthy or competent certificate authority, the fact that there are over 1000 CA certificates trusted by Windows or Firefox, which are owned by hundreds of different organizations , should give all users great pause. Also, if just one of those organizations is run by a government agency, and if they have certain network hardware in place between users and destination servers, then they would be able to perform a targeted man‐in‐the‐middle attack of ostensibly secure communications at will.
What is needed is a communications protocol and accompanying software that encrypts messages, masks the sender and receiver of messages from others, and guarantees that the sender of a message cannot be spoofed, without relying on trust and without burdening the user with the details of key management. In this paper, we propose such a protocol.
We propose a system where users exchange a hash of a public key that also functions as the user’s address. If the public key can be obtained by the underlying protocol, then it can easily be hashed to verify that it belongs to the intended recipient. The data exchanged by the user can also include a version number for forwards capability, a stream number (the purpose of which will be discussed later), and a checksum. Encoded with base58 and prepended with recognizable characters (like BM for Bitmessage), an example address would be: BM‐ nTX1KchxgnmHvy9ntCN9r7sgKTraxczzyE. While certainly more cumbersome than an email address, it is not too much to type manually or it can be made into a QR‐code. Users have already demonstrated this to be acceptable as Bitcoin addresses are similar in format and length . This address format is superior to email in that it guarantees that a message from a particular user or organization did, in fact, come from them. The sender of a message cannot be spoofed.
3. Message Transfer
We propose a message transfer mechanism similar to Bitcoin’s transaction and block transfer system  but with a proof‐of‐work for each message. Users form a peer‐to‐peer network by each running a Bitmessage client and forward messages on a best‐effort basis. In order to send a message through the network, a proof‐of‐work must be completed in the form of a partial hash collision. The difficulty of the proof‐of‐work should be proportional to the size of the message and should be set such that an average computer must expend an average of four minutes of work in order to send a typical message. With the release of new software, the difficulty of the proof‐of‐work can be adjusted. Each message must also include the time in order to prevent the network from being flooded by a malicious user rebroadcasting old messages. If the time in a message is too old, peers will not relay it. If the sender of a message did not receive an acknowledgement and wishes to rebroadcast his message, he must update the time and recompute the proof‐of‐work.
Just like Bitcoin transactions and blocks, all users would receive all messages. They would be responsible for attempting to decode each message with each of their private keys to see whether the message is bound for them.
If all nodes receive all messages, it is natural to be concerned about the system’s scalability. To address this, we propose that after the number of messages being sent through the Bitmessage network reaches a certain threshold, nodes begin to self‐segregate into large clusters or streams. Users would start out using only stream 1. The stream number is encoded into each address. Streams are arranged in a hierarchy.