Bitmessage — Peer-to-Peer Secure “Email”

bitmessage

Download Whitepaper (PDF) | Send me a message: BM-NBzkCCLa2pvtn8bPUmzFsUanRJTVSAYh

Notes:

Bitmessages require proof-of-work before they will be relayed, this is to prevent spamming the network. The system is designed to streamline the exchange of public keys for “email” communications, as well as to address concerns of authentication interception if one of 600+ certificate authorities has been compromised.

Here are two reasons why I think that Bitmessage, or something similar will succeed:

1) Privacy is not modal and is built-in as a part of the protocol

Software guidelines for responding to Freedom of Information Act requests such as for the State of Connecticut recommend that software be decided that

“3. Use of separate tables for exempt and non-exempt data;”

GnuPG for example would not fit these needs because both non-exempt and exempt communications would be grouped together. This could potentially be reason for U.S. government agencies that deal with confidential information to use Bitmessage, since exempt data would be separate. Connecticut is interesting that they have include software as a part of the public record in the Freedom of Information Act, which is pretty important considering many states are now writing software that isn’t available for public audit.

While the whitepaper in concerned about the U.S. National Security Agency “overcollection” of information on emails, this is a concern not only of the NSA but also for many other international intelligence agencies “sniffing” communications. There are several U.S. government agencies that still rely on postal mail for sending confidential information, and could also benefit from a faster means to communicate, especially for gathering intelligence.

For example the Antitrust Division of the Department of Justice privacy policy ( http://www.justice.gov/privacy-file.htm#name ) states:

“Remember that e-mail is not necessarily secure against interception. If your communication is sensitive or includes personal information you may prefer to send it by postal mail instead.”

And the State Department privacy policy ( http://www.state.gov/misc/415.htm ) reads:

“You should be reminded that email may not necessarily be secure against interception. Therefore, we suggest that you do not send sensitive personal data (such as your Social Security number) to us via email. If your intended email communication is very sensitive, or includes information such as your bank account, charge card, or Social Security number, you should instead send it by U.S. mail. Another alternative may be submission of data through a secure web page, if available.”

2) Does not require the trust of ICANN and 600+ CAs

The whitepaper writes:

“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”

The security needs in 2014 have grown and includes health, social and banking information, also over TLS/HTTPS. This could be more than what was anticipated in the original design of TLS/HTTPS. Systems such as Bitmessage do not require root certificates and for certificates to be signed to establish authenticity.

Here are two improvements that I think could be made to Bitmessage:

1) To further help prevent spam it could be useful to require proof-of-relationship

In order for two parties to communicate, they would require the acknowledge acceptance of email from the specific address, and to prevent spamming of proof-of-relationship requests, the proof-of-work concept could be used. This could also be a good means to be able to exchange and verify the recipient on the other end of the address to avoid mistakenly sending a message, since there is little personal information within each Bitmessage address. Furthermore, more identity information could be stored on the blockchain, in a similar way that Twister ( http://twister.net.co/ ) includes a profile image, website, description and location.

2) Physical network security and proof-of-trust

To further improve the security against interception of communications and vulnerabilities in cryptography, trusted relay “streams” could be used based on a similar system of notaries or certificate authorities that are used for TLS/HTTPS security. These trusted relay points could be based on consensus and every participant of the Bitmessage network could sign and revoke other nodes in the network to establish proof-of-trust.