Adi Shamir posed the question in 1984. Could you build a system where a person's public key is simply their name or email address, so a sender needs nothing but the recipient's identity to encrypt to them? The appeal was obvious. The whole apparatus of certificates, key servers, and web-of-trust exists to answer one question: is this public key really theirs? If the key were just the address itself, that question would disappear. Shamir showed how to do it for signatures but left encryption open. It stayed open for seventeen years.
In 2001, Dan Boneh and Matthew Franklin published a practical construction using a piece of mathematics that had mostly been a tool for attacking cryptosystems: bilinear pairings on elliptic curves. Around the same time, Clifford Cocks published a different construction based on quadratic residues. Boneh and Franklin's pairing-based scheme became the one everyone built on, and identity-based encryption, usually shortened to IBE, went from a twenty-year-old open problem to deployable software.
The Setup: One Authority, Many Identities
IBE revolves around a central party called the Private Key Generator, or PKG. When the system starts, the PKG generates a master secret and a set of public system parameters that it publishes to everyone. Those parameters, plus a recipient's identity string, are all a sender needs.
The flow works like this. Alice wants to encrypt a message to bob@example.com. She takes the public system parameters and the literal string bob@example.com, runs the encryption algorithm, and produces ciphertext. She never contacted Bob, never looked up a key, never checked a certificate. Bob, to read it, goes to the PKG, authenticates himself as the owner of that address, and receives the private key that corresponds to it. The PKG derives that private key from its master secret and the identity string. Bob decrypts.
Encryption needs only public information plus the recipient's identity, so anyone can do it at any time, even before the recipient has ever contacted the system. Decryption needs a private key that only the PKG can produce. The public key exists the moment the identity does; the private key is issued on demand.
Why Pairings Make It Work
The mechanism rests on a bilinear pairing, a function that takes two points on an elliptic curve and maps them to a value in another group, with a special property: you can move a scalar multiplier from one input to the output and back. Written loosely, pairing of (a times P, b times Q) equals pairing of (P, Q) raised to the product a times b. This lets the scheme link two secrets that were never combined directly.
In Boneh-Franklin, the recipient's identity is hashed to a curve point. The PKG's master secret is a scalar. The recipient's private key is the master secret applied to the identity point. When Alice encrypts, she uses a fresh random value and the identity point to build the ciphertext so that only someone holding the identity's private key can invert it, and the pairing is what makes the two halves cancel out correctly during decryption. If you want the groundwork under this, our explainer on elliptic curve cryptography covers the curve and scalar operations the pairing builds on.
The security rests on a hardness assumption in the pairing setting, a bilinear variant of the Diffie-Hellman problem. As long as that problem is intractable, an attacker who sees the ciphertext and the public parameters cannot recover the message without the identity's private key.
The Escrow Problem Is the Whole Story
Here is the part the elegance tends to obscure. The PKG derives every user's private key from its own master secret. That means the PKG can derive every user's private key, whenever it wants, without telling anyone. It does not need to break anything, it does not need a court order to compel a third party, it simply computes the key it was always able to compute. This is key escrow by design, and it is not a bug you can patch. It is the mechanism.
In a certificate-based system, your private key is yours and no one else generates it. In identity-based encryption, the authority that issues your key can regenerate it forever. The trust you place in a certificate authority is that it will not lie about whose key is whose. The trust you place in a PKG is that it will not read your mail.
This is a fundamentally different and larger amount of trust. A compromised certificate authority can impersonate you going forward, which is serious, but it cannot retroactively decrypt traffic that was encrypted to your real key. A compromised PKG can decrypt everything, past and present, that was ever encrypted under its parameters. The PKG is a single point that holds the keys to the entire deployment.
What People Do About It
IBE research spent years trying to soften the escrow problem, and the mitigations are instructive because none of them fully removes it.
- Threshold PKGs. Split the master secret across several authorities using secret sharing, so no single one can derive a key alone. This helps only if the authorities are genuinely independent and do not collude. It raises the bar; it does not eliminate the capability.
- Certificateless encryption. A 2003 variant by Al-Riyami and Paterson combines an authority-derived partial key with a user-chosen secret, so the authority alone cannot decrypt. This trades away some of IBE's original convenience, because the sender now needs a user-specific value again.
- Accountable IBE. Schemes that make unauthorized key generation detectable after the fact, so a cheating PKG leaves evidence. Deterrence, not prevention.
The pattern across all of them is the same. You can distribute the trust, make it accountable, or add a user secret, but the closer you get to removing the authority's power, the more you give back the very property that made IBE attractive in the first place.
Where IBE Actually Fits
The escrow property is fatal for private consumer messaging and a feature for certain enterprise settings. A company that wants to encrypt internal email but must retain the ability to read it under compliance rules, or recover a departed employee's mailbox, sees escrow as exactly the recovery mechanism it needs. Voltage Security commercialized IBE-based email encryption in the 2000s on this basis, and the approach found a home in regulated environments. The IEEE and IETF have published IBE specifications for these use cases.
| Property | Certificate-based (PGP, S/MIME) | Identity-based (IBE) |
|---|---|---|
| Get recipient's public key | Look up and verify a certificate | Use their identity string directly |
| Who generates the private key | The user, locally | The central authority |
| Can a third party decrypt | No | The PKG always can |
| Best fit | Private communication between individuals | Compliance and recovery in a controlled org |
It is worth putting IBE next to attribute-based encryption, a later generalization where you encrypt to a policy over attributes rather than a single identity. It shares the same authority-issues-keys structure and inherits the same escrow question, which is a good reminder that the tradeoff is not unique to IBE but baked into the family of schemes where a central party mints decryption keys.
Where Haven Fits
Haven deliberately does not use an escrow model. Your identity keys are generated on your device and protected by a passphrase that never leaves it, so there is no central party that can regenerate them and no master secret whose compromise would unlock everyone. Encrypted email uses PGP for interoperability, and group chat uses MLS, both of which keep the decryption capability with the endpoints rather than an issuer. IBE is a genuinely clever answer to the key-distribution problem, and studying it clarifies the choice we made: the convenience of encrypting to a bare identity is real, but the price is a party who can read everything, and for a private messenger that price is the wrong one to pay.