Secure communication: Bitmessage

Inspired by EFF’s Secure Messaging Scorecard 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 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 the public key used for encryption. For example: BM-2cSwb3miRwL6ZPeKoChP5z1Sqwe5GW2aHL 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…

Is the code open to independent review?
Yes, it is open source. Almost everybody can access it at https://github.com/Bitmessage/PyBitmessage

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 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.