In 2016, a now-famous usability study and a long tail of similar experiences had made one thing clear: traditional PGP was unusable for ordinary people. Generating a keypair was a hurdle. Finding the right public key for a recipient was worse. Verifying that the key actually belonged to that person, through the web of trust or a key-signing party, was a step almost no one completed. The encryption worked perfectly and the human workflow collapsed.
Autocrypt, a specification first published by a group of developers and researchers in late 2017, takes a contrarian position: if perfect key management is the thing nobody does, then stop requiring it. Make encryption automatic and opportunistic, accept a weaker trust model, and raise the floor from "no encryption at all" to "encrypted by default for people who exchange mail." It is less a new protocol than a set of agreements about how existing OpenPGP email should behave so that clients cooperate without user effort.
The Key Lives in the Header
The central mechanism is almost startlingly simple. Every Autocrypt-capable message carries an Autocrypt: header that includes the sender's own OpenPGP public key, encoded inline. There is no keyserver lookup, no separate exchange, no fingerprint to read aloud over the phone. The key rides along with ordinary mail.
When an Autocrypt-aware client receives such a message, it parses that header and quietly stores the sender's public key alongside their address. The next time you compose a message to that person, your client already has what it needs to encrypt — because they told you their key simply by having emailed you once. The whole exchange is invisible.
Classic PGP asks: "prove this key belongs to this person before you trust it." Autocrypt asks: "did this address send me a key? Then use it." It trades strong, verified identity for automatic, frictionless key distribution — a different point on the same curve, chosen on purpose.
Opportunistic, Not Mandatory
Autocrypt is explicitly opportunistic. It encrypts when it can and falls back to plaintext when it cannot, rather than refusing to send. If you have a stored key for every recipient, a client following the spec can offer to encrypt; if even one recipient has never sent you a key, it sends in the clear rather than block the message.
This is a usability decision with security consequences, and the spec is honest about it. Mandatory encryption produces failed sends and frustrated users who turn the feature off. Opportunistic encryption keeps mail flowing and slowly accumulates encrypted conversations as more correspondents become capable. The cost is that an active attacker can sometimes force a downgrade to plaintext, and the user may not notice.
Trust on First Sight, Not Web of Trust
The hardest truth about Autocrypt is what it gives up. It does not verify that the key in the header genuinely belongs to the person who appears to have sent it. It uses a trust-on-first-use model: the first key it sees for an address is the key it uses, much like SSH remembering a host key the first time you connect.
That means an attacker who can intercept and modify mail at the moment of first contact — before you have ever received a legitimate key — can substitute their own key and read the conversation. This is the classic machine-in-the-middle window. Autocrypt does not claim to defend against it. What it does claim is to defend against the far more common passive adversary who simply reads mail in transit or at rest, and to do so for the vast population that would otherwise use no encryption whatsoever.
Autocrypt's guarantee is honest and narrow: it protects against passive surveillance for people who would never have configured PGP by hand. It does not protect against an active machine-in-the-middle at first contact, and it never pretended to.
Gossip and the Setup Message
Two supporting mechanisms round out the design. Key gossip handles group mail: when you send to several people, your client can include their keys (the ones it already knows) in an encrypted part of the message, so the other recipients can learn keys for people they have not yet directly heard from. It propagates keys sideways through normal group conversation.
The Setup Message handles multiple devices. Because your secret key lives on your device, moving to a phone or a second laptop would normally mean a fragile key export. Autocrypt defines a special encrypted email you send to yourself, protected by a numeric setup code, that transfers your key material to another client cleanly. It is a pragmatic answer to the multi-device problem that key-based email has always struggled with.
Where You'll Actually Encounter It
Autocrypt is implemented across a set of privacy-focused mail tools rather than the big webmail providers. Thunderbird's built-in OpenPGP support understands Autocrypt headers; the Android client K-9 Mail and the OpenKeychain app support it; and Delta Chat — a messenger that uses email as its transport — is built around Autocrypt as its core key-management layer, which is arguably its most successful real-world deployment.
| Concern | Classic PGP | Autocrypt |
|---|---|---|
| Key discovery | Manual: keyservers, fingerprints | Automatic: key rides in the header |
| Identity verification | Web of trust, key signing | Trust on first use |
| When it encrypts | When the user chooses to | Opportunistically, when keys are known |
| Defends against passive surveillance | Yes | Yes |
| Defends against MITM at first contact | If fingerprint verified | No |
| Realistic adoption by non-experts | Very low | Much higher |
The Limits Worth Naming
Autocrypt inherits every structural limitation of PGP email that has nothing to do with key exchange. Email metadata — who you wrote to, when, and the subject line in most configurations — remains exposed, because PGP encrypts the body, not the envelope. Forward secrecy is absent: OpenPGP's long-lived keys mean that compromising a private key can expose past messages, unlike modern messaging protocols built on ratcheting keys. And the trust-on-first-use model means verification is still worth doing out of band for high-stakes contacts, even if the spec does not force it.
None of that makes Autocrypt a bad idea. It makes it an honest one. It is an attempt to extract the realistic, deliverable fraction of PGP's promise and ship it to people who were never going to read a fingerprint over the phone.
The Broader Lesson
The deepest takeaway from Autocrypt is about usability as a security property. A perfect cryptosystem that no one configures protects no one. A weaker system that runs by default, on every message, for millions of people, can move the aggregate needle further. Autocrypt chose the second path deliberately, and was transparent about the trade.
That is the same philosophy behind making encryption automatic in a modern messenger rather than an expert toggle. Haven's approach is to derive your keys on your own device and encrypt by default, so the protective behavior is the path of least resistance rather than an option most people never find. Autocrypt proved that the usability problem was the real problem all along — and that solving it, even imperfectly, is what actually gets people protected.