E2EE Key Storage Evolution & Passkey PRFs
I gave a talk at Cork|Sec 156 this month on the evolution of end-to-end encryption key storage, and why passkey PRFs look like the next step in that story.
Here’s a summary of the argument.
The hard part of cryptography is the keys
End-to-end encrypted systems like WhatsApp and Signal have always had to grapple with an awkward question: where do the encryption keys actually live? And more importantly, when you lose your phone, where does access come back from?
Key storage is key recovery. The cryptography is the easy part. The hard part is what happens when a user drops their phone in a river.
This is where E2EE has historically lost to convenience. Telegram doesn’t beat Signal on security. It beats it on “enter your phone number, you’re chatting.” Users consistently choose less friction, even at the cost of a server that can read their messages.
Three generations of E2EE key management
The history of E2EE key storage is a steady migration away from user memory.
Generation 1: password-derived keys. Derive the root key directly from the user’s password through a KDF. The server only ever sees encrypted data. The problem is that a human picked the secret. “123456” has been used over 4.5 million times, and no KDF saves you from that. When you lose your devices, access comes back from a password you remembered. Everything rests on user memory.
Generation 2: PIN + hardware. Signal’s Secure Value Recovery is the canonical design. Users pick a low-entropy PIN, but the PIN-protected backup key lives inside a secure enclave that enforces a hard guess limit; after too many wrong attempts, the secret is destroyed. WhatsApp shipped the same shape with an HSM-backed Backup Key Vault. Juicebox pushed the pattern further with Shamir secret sharing and OPRFs across multiple operators. User memory still matters, but much less of it, and hardware does the heavy lifting.
Generation 3: trusted devices. Apple’s Advanced Data Protection removes the memorized secret from the critical path entirely. Keys sync across a set of explicitly trusted devices, and recovery comes from another device, a recovery contact, or a printed recovery key. Nothing the user has to remember in steady state.
Worth noticing: Moxie Marlinspike walked this entire arc personally. He built Signal’s SVR (Gen 2), co-designed Juicebox (Gen 2.5), and is now shipping what I’d argue is Gen 4.
Generation 4: passkey PRFs
Passkeys changed the FIDO2 story in one crucial way: credentials sync. Old FIDO2 credentials were device-bound, so losing the device meant losing the credential, which is largely why adoption stalled. Passkeys sync through provider infrastructure (iCloud Keychain, Google Password Manager, 1Password), so a new device already has them.
The WebAuthn PRF extension builds on that. A passkey can now produce cryptographic keys, not just authentication signatures. The application supplies a salt, and the authenticator returns a deterministic, high-entropy value derived from the credential. It’s HMAC under the hood, originally the CTAP hmac-secret extension designed for disk encryption.
That means one passkey can do both jobs:
One thing to lose instead of three. Recovery inherits from passkey sync. Hardware-backed by default. The same UX as login.
“Cryptography turns data security problems into key management problems.”
- Moxie Marlinspike
This is deployable now
The primitive is old; cross-platform availability is recent. Chrome shipped PRF support in 2023, Android followed in 2024, and Apple’s iOS 18 / macOS 15 / Safari 18 release in September 2024 put PRF on a billion-plus devices. That was the inflection point. Windows Hello support landed in February 2026. 1Password, Dashlane, and Bitwarden already derive vault keys from PRF outputs.
The cleanest production example is Moxie’s Confer, an E2EE AI chat product. Sign up, and a PRF-capable passkey is created on your device. No password. The PRF output is fed through HKDF to derive a root key, which envelope-encrypts everything else. The server never sees it, and key recovery inherits from passkey sync.
And then there’s the proof at scale: WhatsApp, the largest E2EE deployment on earth. Backups went from plaintext (pre-2021), to a password-protected HSM vault (Gen 2, 2021), to passkey-backed encrypted backups in 2025. One product, three billion users, two generational jumps, and it skipped Gen 3 entirely.
What actually changes
Passkey PRFs are not a cryptographic breakthrough. They’re an engineering simplification that collapses two long-separated key management problems, authentication credentials and encryption root material, into a single primitive.
What gets fixed:
- No per-service PINs
- No backup key escrow ceremony
- No recovery phrase to write down
- No “you will lose everything unless you guard this with your life” warnings
- One credential lifecycle instead of two
The bigger win is that, for the first time, E2EE has a recovery story competitive with non-E2EE systems. Telegram’s advantage was never security. It was friction. Passkey PRFs close that gap.
And because every modern phone and laptop ships with a secure enclave or TPM, every employee already carries hardware-backed key material in their pocket. The trust relocates from servers to client devices that already exist. I wrote more about the enterprise angle in Passkeys and the Quiet Revolution in Corporate Crypto.
Credits
The work that brought passkey PRFs from spec to production E2EE: Adam Langley and the WebAuthn WG wrote the PRF extension spec; Matthew Miller introduced PRF-for-encryption to web developers in 2023; Kevin Lewi documented WhatsApp’s OPAQUE + HSM backup design at RWC 2023; 1Password shipped the first major production use in 2024 and open-sourced their library; Filippo Valsorda brought cryptographer-grade design to PRF file encryption with typage; and Moxie Marlinspike’s Confer gave the clearest public framing of why this matters.