Authentication and Forward Secrecy in Bleep

Arvid Norberg —  December 11, 2014 — 1 Comment

There are two central components in any secure communication: authentication and confidentiality. Authentication is the ability to be certain that the other end of a conversation is who you expect it to be. Confidentiality is your ability to communicate without an eavesdropper discerning what you are saying. In Bleep, we’ve also taken steps to obfuscate that you are talking to somebody, by not having a central repository of all metadata.

Confidentiality is close to pointless without authentication. If you cannot be certain that you’re talking to the right person, you may be talking to the eavesdropper. The eavesdropper could even talk to the right person and forward your messages to hide his or her presence.

Authentication is typically provided by introducing trusted third parties. On the web for instance, there are several trusted entities (certificate authorities) that have the ability to issue certificates tied to websites’ hostnames. This allows your browser to verify that the certificate a site provides matches the site the user intended to go to.



In Bleep, each user in the system generates his or her own cryptographic identity, a keypair. The private key is not shared with anyone, including BitTorrent Inc. This is an important distinction. BitTorrent Inc. never sees this private key and therefore does not have the ability to decrypt or impersonate the user. The public key is shared with everyone you add to your contact list. To tie a public key to a person, BitTorrent Inc. provides a certificate authority-like service, verifying email addresses and phone numbers and tying public keys to them. Users can also exchange public keys in person, not involving any servers, and without having to trust any third party.

Once two people know each other’s public keys, they can both authenticate each other, establishing an entirely private channel of communication, with certainty that the other end is who they claim to be.

An important property of our encrypted tunnels is forward secrecy. This is the property that each message, once delivered, cannot be decrypted again, even if you have one of the private keys for one of the users involved. The way this works is by establishing a temporary keypair for each conversation. For each message the keypair is transformed on both ends such that the next message is encrypted with a different key, and the previous key is deleted. This transformation is via a one-way function, meaning that it cannot be reversed. This mechanism is commonly referred to as ratcheting: stepping the encryption key forward without being able to ever step backwards.

The upshot of this is that any eavesdropper that records all of your encrypted communication cannot go back and decrypt it later if they manage to get a hold of your private key.

Arvid Norberg


Arvid Norberg is the Chief Architect at BitTorrent, Inc., a veteran of the µTorrent team, one of the key members of the BitTorrent Chat development team, and expert in peer-to-peer technology.