Bitmessage — Peer-to-Peer Secure “Email”
Download Whitepaper (PDF) | Send me a message: BM-NBzkCCLa2pvtn8bPUmzFsUanRJTVSAYh
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:
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.
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:
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.