Secure communication: Bitmessage

Inspired by EFF’s Secure Messaging Scorecard (update: there is now a dedicated website for secure messaging apps comparison) I have decided to analyze some not so well-known secure messaging applications. I am going to analyze only open-source solutions and the first application is Bitmessage. Bitmessage is a decentralized, encrypted, peer-to-peer, trustless communications protocol written in Python with Qt GUI.

Encrypted in transit?

Yes, it is. Bitmessage uses elliptic curve cryptography library - it’s OpenSSL wrapper - PyElliptic, to encrypt all messages. Metadata as message subject are also encrypted.

Encrypted so the provider can’t read it?

Yes, all the communication is end-to-end encrypted. Bitmessage uses trustless peer to peer (P2P) network and the messages are redirected by every other user. Every client within a network try to decrypt and read all messages that passes through her connection, but only legitimate one with the corresponding private key can read the message.

Can you verify contact’s identities?

Yes, the address of the recipient is actually RIPEMD-160 of SHA-512 of the public key used for encryption together with some other protocol data. For example: BM-2cUsoFSfWHfwYjFSgyqtzt8WnAEQa2YzKk is a valid address. Note that BM prefix is used for recognition of the Bitmessage protocol.

Are past communications secure if your keys are stolen?

No, there is no forward secrecy built in by default. Personally, I think this is the biggest weakness of the whole protocol. Not only that attacker can read your messages after obtaining the private key, but she is able to collect all the traffic easily upfront due to architecture of Bitmessage itself. As I said previously, all the messages are routed through P2P network and are already in the attacker’s node memory, so she can go through them and try to decrypt all past messages. According to the Bitmessage maintainer, Peter Šurda, there are two proposals for the forward secrecy, so it’s probable that this feature will be added to the protocol in the future.

Is the code open to independent review?

Yes, it is open source. Almost everybody can access it at GitHub

Is the crypto design well-documented?

Yes, the author provides specification along with examples at the project wiki page. You can find threat model and a lot of other valuable information in white paper too. However, let’s talk a little bit about key management here. As only a single asymmetric ECC key is used for specific address forever, the only way to revoke it is not to use that address / key, and delete corresponding private key.

Has there been an independent security audit?

No. There was an attempt to get it audited by Kristov Atlas, but the audit did not happen.

Tor interoperability

Yes, Bitmessage is using socks library and can be set to use Tor for traffic routing. However, Bitmessage is not using encryption between nodes and is therefore open to possible Sybil attack from the Tor exit nodes. As I know, opportunistic encryption is implemented in forked repositories, and probably will be merged into the main repository in the future.

I2P interoperability

Partially. Main repository does not implement I2P protocol support, but fork working only via I2P exists on Github.

Network type

Peer-to-peer network based on Bitcoin P2P network implementation. We can consider it high latency network because of random delays introduced in object processing.

Conclusion

Bitmessage is a really nice concept which is trying to achieve the linkability resistant protocol design. It hides metadata pretty well at the cost of future network scalability. Usage is quite limited due to Proof-of-work computation when sending messages and requesting public keys of the message receivers. The mix-net like design of this protocol can remind experimentation with early days anonymous remailers.

UPDATE:
2017-01-07 - Bitmessage maintainer Peter Šurda wrote me, that the opportunistic encryption is already used by Bitmesage. By his own words, “The merged code includes opportunistic encryption. At some stage in the future, non-encrypted connections will be disabled, but still many people use old version, so I don’t want to do that yet.”