How to Implement End-to-End Encryption

A production walkthrough from a team that chose where to draw the line, and where we couldn't.

Key Takeaways

• Knowing how to implement end-to-end encryption is less about the cryptographic primitives and more about the ugly decisions around key recovery, multi-device sync, backup, and metadata leakage.
• MLS (RFC 9420) is the right default for group encryption in 2026. The Signal Protocol still holds for 1:1. Pick one; do not invent your own.
• If your product involves server-side AI inference, true E2EE over the full data path is not currently possible. Acknowledge this publicly or you are lying to your users. TEE-based confidential inference is the closest practical option today.
• Metadata is the second front most teams ignore. Encrypting message content while leaking who talks to whom, when, from which device, and from which IP is a half-measure.
• Key recovery and multi-device support are where almost every real-world deployment quietly compromises its E2EE guarantees. Budget more engineering time here than on the cipher math.

What does "end-to-end" actually mean in production?

It means plaintext exists only on the endpoints. Not "encrypted in transit." Not "encrypted at rest on our servers." The server is hostile by design: it stores ciphertext, routes ciphertext, and never possesses the key material to do anything else. If your server can read the content, you have transport encryption, not end-to-end encryption. The distinction matters because users cannot verify the difference from outside, and marketing departments routinely blur it.

A useful mental model: draw the line where plaintext appears. If that line ever touches your infrastructure, it is not E2EE for that data. This sounds obvious until you start shipping features. Backups that land in an unencrypted cloud bucket? Not E2EE anymore. A search index you build server-side so users can find old messages? Not E2EE. An AI assistant that processes user content on a remote GPU? Not E2EE. These are the real design pressures. The cipher selection is a solved problem by comparison.

Which protocol should you use?

For 1:1 messaging, the Signal Protocol (Double Ratchet + X3DH) remains the standard. For group communication, MLS (RFC 9420) is now the correct choice. It was published in July 2023 and provides asynchronous group key establishment with forward secrecy and post-compromise security for groups from two members to thousands.

MLS exists because the Signal Protocol's group encryption does not scale. In Signal's approach to groups, each message is individually encrypted to every member, which means send cost grows linearly with group size. MLS uses a tree-based key structure (TreeKEM) that brings this down to logarithmic. For a group of 1,000 members, that is the difference between encrypting a message 1,000 times and roughly 10 times.

The real-world adoption curve has accelerated. In March 2025, the GSM Association announced that RCS Universal Profile 3.0 would adopt MLS as its E2EE standard. By mid-2026, both major mobile platforms had begun active MLS-based E2EE rollout for RCS, making it the first large-scale interoperable E2EE deployment across different platform providers.

Do not build your own protocol. If you are reading this article for guidance, you should not be designing novel key agreement schemes. Use a vetted implementation of Signal or MLS, audit the integration points, and spend your engineering time on the actually hard problems described below.

How do you handle key management without losing users?

Key generation is straightforward. Each client generates a long-term identity key pair and a set of prekeys (one-time-use public keys uploaded to the server). The server stores these prekeys so that another user can initiate an encrypted session asynchronously, without both parties being online. This is the X3DH handshake in Signal, and a similar mechanism exists in MLS for adding members to a group.

The hard part is everything that comes after. You need to think about three scenarios that will cause you real production pain.

What happens when a user gets a new device?

Multi-device support under E2EE is genuinely difficult. The server cannot decrypt and re-encrypt messages for the new device, because the server never has plaintext. So you have two options: treat each device as a separate participant in every conversation (which means messages are encrypted once per device, and adding a phone means re-keying every active session) or sync private key material between devices.

Device-as-participant is simpler to reason about but creates a metadata problem: every conversation partner can see how many devices you have. It also inflates bandwidth. Key sync is more efficient but requires a secure channel between your own devices, and bootstrapping that channel when one device is new and untrusted is a chicken-and-egg problem.

We have seen teams punt on this by supporting only single-device E2EE. That is a valid choice if your threat model supports it, but your users will not understand why they cannot see their messages on their laptop.

What happens when a user loses all their devices?

This is the key recovery problem, and it remains unsolved in any satisfying way. The common approaches each carry a specific failure mode:

• Recovery codes. A random string the user writes down at registration. In practice, users lose the paper. Or they store it in a notes app that backs up to the cloud, which defeats the purpose.
• Shamir Secret Sharing across trusted contacts. You split the recovery key into shares distributed to friends, requiring some threshold to reconstruct. The authentication problem here is real: when a contact receives a reconstruction request, they have no reliable way to verify it is genuine and not a social engineering attack.
• Server-held key escrow protected by a user passphrase. This reintroduces server trust. The passphrase is typically low-entropy, so the server (or anyone who compromises it) can brute-force the key offline.
• Hardware security keys. The most robust option, but adoption is minimal outside high-security enterprise environments.

Every shipping E2EE product has made a compromise here. Most do not document which one. You should.

What about backups?

Encrypted backups are where E2EE guarantees go to die quietly. A user who backs up their chat history to a cloud storage service in unencrypted form has effectively opted out of E2EE, even if every message was encrypted on the wire. The cloud provider can read the plaintext copy.

If you offer backups, encrypt them with a key the user controls. If you do not offer backups, users will screenshot or export, and you have no control over what happens next. There is no clean answer. Just make the tradeoffs visible to the user and to yourself.

Why is metadata the part most teams underinvest in?

Because content encryption is the part that shows up in the marketing page, and metadata reduction is invisible, expensive, and hard to verify externally.

Even under full E2EE, your server sees: who is communicating with whom, when, how often, from which IP addresses, on which devices, and for how long. This metadata can be extremely revealing on its own. Knowing that a journalist contacted a government whistleblower at 2 AM from a location near the parliament building is useful intelligence even without the message content.

Concrete steps you can take, roughly ordered by effort:

1. Minimize server-side logging. Log what you need for abuse prevention and nothing else. Define "need" narrowly and review it quarterly.
2. Strip or pad message sizes. Message length can reveal content type (a short text vs. a file transfer). Pad all ciphertext to fixed block sizes.
3. Consider sealed-sender designs. Signal pioneered this: the sender's identity is encrypted inside the message envelope so the server routes messages without knowing who sent them. It is not trivial to implement, and it is not perfect (the server still sees the recipient and the sender's IP), but it reduces the metadata surface meaningfully.
4. Avoid third-party analytics on encrypted flows. If you are sending events to an analytics provider every time a user opens an encrypted conversation, you are leaking metadata through a side channel. This sounds obvious, but we have seen it in production codebases from teams that should know better.
5. Use a short retention window for operational metadata. You will need some metadata for rate limiting, abuse detection, and debugging. Retain it for the minimum window required and then delete it. Not "mark for deletion." Delete.

How does E2EE interact with AI features?

Badly. This is the central tension for any product that combines encryption with server-side intelligence, and we have spent more design time on this than on any other problem in the stack.

The core issue is simple: a large language model needs plaintext to generate a response. If the model runs on a remote server, and user content reaches that server as plaintext, the path from user to server is not end-to-end encrypted. It cannot be, by definition. Any product that claims otherwise is either confused or dishonest.

An academic framing from late 2024 lays out the design space clearly. There are a few architectural options, each with distinct failure modes:

On-device inference

Run the model locally. Plaintext never leaves the device. This preserves E2EE perfectly but limits you to small models with constrained capabilities. If your product needs frontier-grade intelligence, this is currently not viable for the primary inference path.

Fully homomorphic encryption (FHE)

The theoretical ideal: compute on ciphertext without ever decrypting it. Proton's engineering team has noted that current FHE experiments produce response times exceeding a day for workloads that take milliseconds in plaintext. The math works. The performance does not. Check back in five years.

TEE-based confidential inference

Trusted execution environments (enclaves) where plaintext is decrypted inside a hardware-isolated boundary, processed, and re-encrypted before leaving. Some inference platforms now offer this architecture, where prompts arrive as ciphertext and are decrypted only inside a verified TEE. This is the closest practical option to E2EE for server-side AI today, but it shifts your trust from the service operator to the hardware vendor and the attestation chain. It is a real improvement. It is not the same thing as E2EE.

Cleartext to server with strict minimization

Accept that plaintext reaches the inference provider. Minimize what is sent, control how long it persists, and be transparent about it. This is what most AI products actually do, including us. Selina's memory is encrypted at rest, but a slice of each request reaches a frontier provider at inference. Memory is not end-to-end encrypted. Files and transfers via SelinaSEND are zero-knowledge encrypted. We draw the line there and say so plainly.

The honest version of this approach requires you to do the boring work: contractual data processing agreements with your inference providers, aggressive prompt minimization (send the minimum context needed, not the full history), short retention windows for any operational metadata, and clear documentation for users about what is and is not encrypted.

What is the "encrypt-before-embed" bug class?

This one comes from our own production experience, and we have not seen it written up elsewhere.

If your system generates embeddings (vector representations) of user content for search, retrieval, or memory features, the order of operations matters critically. If you embed first and then encrypt the original content, the embeddings themselves are an unencrypted representation of the content. They are lossy, yes, but research has shown that text can be partially reconstructed from embeddings. You have encrypted the front door and left the side window open.

The correct approach is to treat embeddings as derived content that inherits the same protection level as the source material. If the source is encrypted at rest, the embeddings must be encrypted at rest with equivalent key management. If the source is E2EE, the embeddings must be generated client-side (which has obvious performance implications for large corpora).

We found this bug in our own system during an internal review. The embeddings were stored in a vector database with different access controls than the source content. The fix was straightforward once identified, but the class of error is subtle: any derived representation of encrypted content is a potential plaintext leak. Summaries, indexes, feature vectors, cached search results. Audit every derived artifact.

How should you think about post-quantum readiness?

Start now, but do not panic-ship.

The timeline for cryptographically relevant quantum computers has compressed. Recent research has revised downward the qubit count needed to break RSA-2048, from roughly 20 million to fewer than 1 million. The "harvest now, decrypt later" threat model (an adversary records your ciphertext today and decrypts it in five years when quantum hardware matures) means that data with long-term sensitivity needs quantum-resistant encryption now, not when quantum computers ship.

The practical step: use hybrid cipher suites that combine a classical algorithm (like ECDH) with a NIST-approved post-quantum key encapsulation mechanism (like ML-KEM). MLS is designed to support this, and newer implementations already offer hybrid suites. You get the battle-tested security of classical crypto as a floor, with post-quantum protection as the ceiling. If the post-quantum algorithm turns out to have a flaw, you fall back to classical security rather than to nothing.

Do not roll your own post-quantum implementation. Use a library that tracks NIST standards. Update when the standards update.

What does interoperability regulation mean for your E2EE implementation?

If you operate in the EU, this is no longer hypothetical. Cross-platform messaging mandates require that users on one encrypted service can communicate with users on another. Even when both services use the same underlying protocol, differences in session storage, key derivation, and backup methods can degrade security at the integration boundary.

The engineering complexity is real. You need to agree on: which ciphersuites to support, how to handle key verification across platforms, what happens to forward secrecy when one side rotates keys at a different cadence, and how to present trust indicators to users when the other side's implementation is opaque to you.

This is an area where standards help enormously. MLS was designed with multi-provider interoperability in mind, and its adoption by RCS demonstrates that it works at scale. If you are building a new E2EE system today and there is any chance you will need to interoperate with others, build on MLS rather than a bespoke protocol. The cost of migration later is significantly higher than the cost of adopting it now.

What is the minimum viable E2EE implementation?

If you are an engineer tasked with adding E2EE to an existing system, here is the shortest path to a defensible implementation, in order of priority:

1. Pick a protocol. Signal Protocol for 1:1. MLS for groups. Use a maintained open-source library. Do not fork it unless you have a cryptographer on staff.
2. Generate and store keys on the client. Identity keys never leave the device. Prekeys are uploaded to your server. Use the platform keychain (iOS Keychain, Android Keystore) for key storage, not your app's sandbox.
3. Encrypt before send, decrypt after receive. Your server should never see plaintext. If you find yourself writing a server-side function that touches cleartext message content, stop.
4. Handle the multi-device case explicitly. Decide whether each device is a separate participant or whether you sync keys between devices. Document the tradeoff. Ship one approach; do not leave it ambiguous.
5. Encrypt backups or do not offer them. If you offer cloud backup, encrypt the backup with a key derived from a user-held secret. If you cannot do this, disable cloud backup and tell users why.
6. Reduce metadata. Minimize server-side logging. Pad message sizes. Retain operational metadata for a short window only.
7. Audit derived data. Every index, embedding, summary, or cache derived from encrypted content is a potential leak. Enumerate them. Encrypt them at rest with equivalent controls.
8. Plan for key loss. Decide on a recovery mechanism. Document its failure modes. Be honest with users about what "lose your key" means (it means lose your data, or it means reduced security guarantees, depending on your recovery design).

This list is ordered by "if you skip this, nothing else matters." Step 1 takes an afternoon. Step 8 takes months of design iteration and you will still not be fully satisfied with the answer.

Where do we draw the line?

Every E2EE implementation is a set of tradeoffs documented as architecture. The Signal Protocol maximizes security for 1:1 communication but does not scale to large groups. MLS scales to large groups but adds complexity in key tree management. On-device AI preserves encryption but limits model capability. TEE-based inference expands capability but shifts trust to hardware vendors. Key recovery improves usability but weakens the security guarantee. Every choice closes a door.

The responsible engineering practice is not to pretend you found a way to avoid the tradeoffs. It is to enumerate them, pick a position, and tell your users where you stand. The teams that earn trust in this space are not the ones with the most aggressive encryption claims. They are the ones who can explain exactly what is encrypted, what is not, and why.

If you want to see how we made these tradeoffs in a privacy-focused AI assistant that remembers you across conversations, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io