Meta revealed on May 1 how they store keys for your WhatsApp backups. I break down the architecture and compare

On May 1st, a post titled "How Meta Is Strengthening End-to-End Encrypted Backups" was published on Engineering at Meta. On May 11th, a follow-up about Labyrinth 1.1, the Android implementation, was released. I read both, then dug into the whitepaper, then compared it to what I'm building myself, and decided to write an analysis. This isn't a rehash of marketing material — it's a proper technical deep dive. What they did, why they chose that approach, where I ran into pain points along the way, what tradeoffs they picked, and what tradeoffs I went with.

First, an important note about what this article covers. It's not about in-transit message encryption. Signal Protocol, Double Ratchet, X3DH — all of these have been the standard for ages, every reputable messenger uses them. WhatsApp licensed Signal Protocol back in 2016. In-transit encryption is a solved problem.

This article is about the next link in the chain, which is still broken for most users. Backups.

Where the gap was

Picture this. You send a message on WhatsApp. It gets encrypted on your phone with a key no one except the recipient knows. It arrives at WhatsApp's servers in encrypted form, so the server can't read it. It flies to the recipient's device, where it gets decrypted. This has all worked since 2016.

Next, the story takes a less flattering turn. Once a day, your WhatsApp backs up your chats to iCloud (on iPhone) or Google Drive (on Android). And until recently, this backup was stored by Apple or Google in plaintext. That means Apple could read it directly, and Google could as well. At the request of law enforcement agencies from any country, these backups were handed over. Several high-profile criminal cases in the US were resolved exactly this way: the suspect had been communicating via WhatsApp, and the prosecution obtained their iCloud backup.

What it came down to was that the messenger had end-to-end (E2E) encryption, but this protection did not exist at the system-wide level. This is because one of the two people chatting almost always backs up their conversations to the cloud, and through that backup, a third party gains access to all of their messages.

In 2021, Meta made its first move and added E2E encryption for backups. That was also when I read their whitepaper for the first time, and I thought the team there was pretty odd: they left half the details for later, described the core component (HSM fleet) in just three paragraphs, and nothing made sense. I waited five years for a proper breakdown of it.

I finally got my wish. In May 2026, Meta finally released the full picture, and as a bonus took the next step: over-the-air distribution of the fleet's public keys, and independent auditability via Cloudflare. Let's break it down.

Basic Threat Model

Before we dive into the architecture, we need to understand exactly what we are protecting. Who we are protecting against is a separate question, and there are several relevant roles to consider.

The end user. They want to be able to access their backup after switching devices. If they forget their password, there must be a way to recover the backup. But recovery shouldn't be so straightforward that anyone else could use it.

Cloud provider. Apple iCloud, Google Drive. They physically store the encrypted backup blob. The threat from them is that they may attempt to decrypt it. If they only have the encrypted blob without the key in their possession, they are powerless.

Meta itself. It plays a key role in the entire design. Meta manages the key verification infrastructure. If the architecture is built in such a way that Meta alone, without user involvement, can recover the key, that means Meta can do anything. This is a bad model. A good model is one where Meta manages the infrastructure, but even Meta itself cannot decrypt without knowledge of the user's password.

The state. This is the most uncomfortable role for system designers. The state can approach Meta with a court order and demand the key be handed over. If Meta can hand it over, it will do so sooner or later. If Meta is physically incapable of doing so, the demand becomes meaningless.

Internal insider. Meta employee with admin privileges. Can this person acting alone steal the keys? Can a group of several people do so? This attack vector is always underestimated.

The goal of the architecture is to build a system where only two parties know the backup key: the user and the HSM fleet. Moreover, the HSM fleet must be designed in such a way that even Meta as an organization cannot force it to hand over the key without the user's involvement.

Building such a system is difficult. Meta built it on three components: HSM fleet as a distributed quorum, the OPAQUE protocol for registration and password verification without disclosure, and independent auditing via Cloudflare. We will go over each component in detail below.

HSM fleet: why a single unit is not sufficient

HSM stands for Hardware Security Module. It is a piece of hardware that can store cryptographic keys and perform operations with them internally, but never releases the keys externally. Even physical access to the circuit board does not allow reading the keys. It usually has built-in anti-tampering functionality: if someone attempts to open it, the keys will self-destruct.

A single HSM is powerful, but not sufficient. There are several issues with this setup. First, an HSM can suffer physical damage. If it holds the backup key for tens of millions of people and it burns out, that is an extremely bad day. Second, a single HSM is both a single point of failure and a single point of compromise. If someone gains physical access and extracts the keys via some exotic method (theoretically possible through side channels, thermal attacks, and other means), they will gain access to all of them.

This is why Meta does not use a single HSM, but a fleet of them. These HSMs are geographically distributed across multiple data centers. Operations are replicated via majority consensus, meaning that to confirm an operation, approval from the majority of nodes in the fleet is required. This provides two key guarantees. Failure of multiple nodes will not take down the service. And to compromise the keys, one would need to simultaneously breach the majority of geographically dispersed nodes, which is incomparably more difficult than breaching a single HSM.

Each node in the fleet has its own key pair. The public part of the pair is used by WhatsApp clients to establish a secure session. The private part never leaves the HSM.

A logical question naturally arises here. How does a WhatsApp client know it is communicating with a legitimate Meta HSM fleet, rather than a spoofed server? In WhatsApp, this is solved with a straightforward approach: the fleet's public keys are hardcoded into the app code. When the fleet is updated, the app is updated, and an update is released via the App Store. It works.

But this approach was not suitable for Messenger. Messenger updates its HSM fleets more frequently than app updates are released. That is why in May 2026, Meta introduced an OTA mechanism for distributing fleet public keys. And this is where Cloudflare comes into play.

Cloudflare as an Independent Witness

When a Messenger client connects to an HSM fleet, the fleet returns its public key as part of the so-called validation bundle. This bundle is signed by Cloudflare and co-signed by Meta itself.

Why is Cloudflare needed here? If Meta were the sole signer of the bundle, Meta could release a bundle with a spoofed key at its own discretion and push it to users. The user would establish a secure session with a spoofed HSM that actually belongs to Meta or the government, and would inadvertently leak their password.

In this scheme, Cloudflare acts as an independent witness. It independently validates that the key belongs to a legitimate deployment, signs the bundle, and maintains a public audit log of all issued bundles. Any researcher can access it to check exactly which keys have been issued and whether any substitution has occurred.

The architectural approach here is interesting. It does not make Meta a trusted party. It adds a second party that has no particular reason to collude with Meta to carry out a substitution. The audit log is public, anyone can view it, and any substitution will be visible.

The scheme also has a weak point, and that is Cloudflare itself. If Cloudflare is compromised or forced to cooperate, the entire system breaks. Cloudflare is a US company, and in cases of national security, it is also subject to the same subpoenas as Meta. In other words, the architecture protects against ordinary civil requests and against situations where Meta wants to snoop. It does not fully protect against FISA warrants.

OPAQUE: the password no one knows

The most elegant part of the entire system.

Here is the task. A user wants to protect their backup with a password. They will memorize the password in their head. When restoring the backup on a new device, they will enter the password and should receive the backup key. The server needs to verify that the password is correct.

The simple solution is for the server to store the password hash, compare it when the password is entered, and issue the key if they match. This is a bad solution. If the server is compromised, the hash will leak, and it can be brute-forced offline. If the server is malicious, it can one day simply hand over the key without verification.

OPAQUE solves both problems. It is an asymmetric password authentication protocol developed at an academic institution in 2018 and standardized by the IETF in 2024. The concept is straightforward. The user and server perform a cryptographic exchange, as a result of which the server mathematically verifies that the user knows the password, but never sees or stores the password itself. It does not even store the hash in the conventional sense.

In Meta's architecture, this works as follows. During initial backup setup, the client generates a 256-bit key via CSPRNG. This key needs to be stored somewhere in such a way that it can only be recovered later with knowledge of the password. The client initiates OPAQUE registration with the HSM fleet: the password is entered, ephemeral values are generated, and a special device-bound record is stored in the HSM. The password itself vanishes into thin air: the client does not transmit it in plaintext, and the HSM never sees it.

When recovering on a new device, OPAQUE authentication is initiated. The client proves to the HSM that it knows the password without revealing it. The HSM verifies the validity of the proof and issues the key. If the password is incorrect, the proof will not hold, and the key will not be issued. Brute-forcing over the network is impossible, because the HSM tracks attempts and blocks after too many failed attempts.

There is also a key detail to note. Even if someone obtains a full memory dump of the HSM (which is nearly impossible, but let's assume it happens), they will not be able to extract the password from it, nor recover the keys without performing an OPAQUE exchange with the legitimate key pair. The attacker will get dead data, from which nothing can be extracted without knowledge of the password.

To my taste, OPAQUE is one of the most elegant pieces of work in applied cryptography from the past decade. If you want to dive deeper, the original paper is titled «OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks», authored by Jarecki, Krawczyk, and Xu in 2018. It was standardized as RFC 9807 in August 2024.

What Meta did not show

This is the critical part. Without it, this is just a press release, not an analysis.

First. The whitepaper describes the protocol, but it does not cover the physical security of the data centers where the HSMs are located. This is understandable: such information is classified and must remain classified. But this means that an internal insider with physical access could still potentially carry out malicious actions. We do not know how many people are granted access to the HSMs, or what separation of duties procedures are in place there.

Second. Cloudflare only functions as an independent party if Cloudflare is truly independent. If it turns out tomorrow that the CEOs of Meta and Cloudflare have private side agreements, or if both companies receive a secret order from the FBI at the same time, the scheme will not work. This is an unavoidable flaw in any architecture that relies on two US corporations.

Third. The "password protects key" model has a fundamental limit. If a user sets their password to "1234", no cryptography will be able to help them. The HSM of course blocks network brute-force attacks, but if the password is weak and an attacker somehow obtains an offline copy of the OPAQUE record (via an insider, or via an exploit in the HSM), they can run a dictionary attack. The protection here relies more on procedural restrictions than on cryptographic strength.

Fourth, and this isn’t even a criticism. Meta’s architecture is extremely expensive. It relies on HSM fleets across multiple data centers, integration with Cloudflare, audits, a whitepaper, and a full-time team of cryptographers. All of this costs tens of millions of dollars per year. It pays off for a large corporation with a billion users, but is completely unfeasible to tackle head-on for a solo developer or small team.

At this point, it makes sense to shift to how I solve this same task.

How it works in ONEMIX

A few introductory notes. ONEMIX is a messenger I am building as a solo developer. It features a React Native client, FastAPI backend, E2E encryption via the Double Ratchet protocol, and voice and video calls via WebRTC plus LiveKit. I am not Meta. I don’t have millions of dollars to spend on HSM fleets in Chicago, Dublin and Singapore with majority-consensus replication. Right now I have one rented server, and I plan to get a physical server based in Russia down the line.

That’s why my backup architecture is built on a completely different core principle. Not "we secure the server key well", but "we don’t have a server key at all". This is called server-blind architecture, and the tradeoffs here are exactly the opposite.

To be specific. Backups are encrypted on the user’s device with a locally generated 256-bit key. The key is never sent anywhere. Nowhere at all: not to the server, not to any third party. The encrypted backup blob is sent to the server without the key. The server only sees an encrypted jumble of bytes and is physically unable to do anything with it.

Recovery works via a recovery phrase. 24 BIP-39 words, just like in crypto wallets. The user saves this phrase for themselves during initial setup. On a new device, they enter it again, and the same 256-bit key is derived from it via PBKDF2 + HKDF, which is used to decrypt the backup stored on the server.

This approach has an obvious advantage and an equally obvious drawback. The advantage is clear: as the service operator, I cannot read anyone's messages, because I have nothing that could be tortured for information. The government cannot come to me with a warrant and demand I hand over keys. I have nothing to hand over. The OPAQUE protocol is unnecessary, because there is nothing to verify. HSM is unnecessary, because there is nothing to store.

The drawback is that if the user loses their recovery phrase, that's it. No recovery via security question, no "forgot your password, answer your mother's maiden name", no support request. All chats are permanently lost along with the phrase.

That is by design. Meta has chosen one compromise: users can recover via a password, but this comes at the cost of a complex infrastructure built on HSM and Cloudflare, plus an unavoidable theoretical reliance on US jurisdiction. I have chosen a different path: the user is solely responsible for their own keys, but in return they get a genuine, independent privacy guarantee that does not depend on my actions.

Which approach is more correct depends on the user's threat model. For the billion ordinary people who mix up their email password with their bank card PIN code, Meta's approach is better. They physically cannot handle a recovery phrase. For an audience that needs maximum security guarantees, the ONEMIX approach is better, because there is no third party you need to trust there.

I am honest with both types of users: if you need a messenger for everyday life with quick account recovery, stay with WhatsApp, they handle that well. If you need a messenger for conversations that absolutely must not fall into the wrong hands, and you are ready to store 24 words yourself, onemix.me.

What you can take away from this

I wrote down several technical observations for myself after reading whitepapers and comparing them with my own code.

OPAQUE is worth looking into. If you are building any system where a user needs to be able to recover a secret via a password, while the server must not see the password, check out OPAQUE. RFC 9807 is short, and libopaque is available for several programming languages. For my own internal use cases, I plan to integrate it into my admin panel to stop storing full password hashes for admin accounts entirely.

Architecture with an independent witness via Cloudflare is a strong approach. Cloudflare does not initially claim the role of an independent certifying party, but effectively becomes one. This pattern can be used in any system where two parties do not fully trust each other. Add a third party that has no interest in colluding, and the scheme becomes significantly more robust. I am thinking of implementing something similar for my key server — it is not yet implemented, but the direction is clear.

HSMs are not just for fintech. In my view, HSMs until recently were only associated with banking processing and certificate authorities. Meta shows that for messengers with a billion users, this is also a reasonable compromise. For smaller scales, there are software HSMs, such as SoftHSM, which provide some of the same guarantees without the capital costs of hardware.

Server-blind as an alternative. If you can afford to tell users "store your recovery phrase yourself", you can build a system that is fundamentally simpler and fundamentally more secure than any HSM flow. It is not suitable for everyone. Bitcoin, MetaMask, and Session are all built this way.

And most importantly. E2E in transit without E2E in backup is half the solution. If your Double Ratchet works perfectly, but your backup is stored in cloud storage in plaintext, your E2E only works for the segment between two phones. It leaks at the edges. You need to treat backups and storage with the same level of seriousness as transit, otherwise all the work done on transit cryptography is nullified.

Meta's post itself is short, but the whitepaper linked in it is well worth spending an evening on. Especially if you are building your own project in the field of privacy and secure communication.

I have been building the project for over a year now. On my Habr blog, I publish breakdowns of individual ONEMIX components (Double Ratchet, message cache, call stack selection), and this is essentially the same kind of open, installment-style whitepaper as Meta's, just much smaller. I will answer any questions left in the comments, and I respond to critique from cryptographers with great interest.