End-to-end encryption explained: what it is, what it is not, and how UmbrellaX implements it

End-to-end encryption, E2EE, means only the sender and the intended recipient can read a message. The server that routes it cannot. The company that runs the server cannot. A state that subpoenas the company cannot read the content. E2EE does not protect metadata, does not protect a stolen unlocked device, and does not protect against someone you yourself invited into the conversation. The two protocols that matter for messaging in 2026 are the Signal Protocol and MLS (RFC 9420). I run UmbrellaX on MLS with post-quantum hardening, and the rest of this piece is me walking through what that actually means at the byte level and why I made the calls I made.

Below: what E2EE is at the byte level, the two protocols worth knowing, what E2EE does not protect, and how UmbrellaX implements it.

What E2EE means in plain bytes

Picture a postcard versus a sealed letter. A postcard is readable by every postal worker who touches it. A sealed letter is readable only by the addressee, assuming the envelope is opaque and the seal intact. E2EE is the digital sealed letter. When I send a message from my phone, it leaves the device already unreadable to anyone except the recipient. My server knows where to deliver it and roughly when. The content stays inside the envelope.

The cryptography works like this. Your device holds two keys for every conversation: a private key that never leaves the device, and a public key you give to anyone who wants to send you a message. The sender encrypts with your public key and sends ciphertext. Only your private key decrypts that ciphertext. When my server reads the ciphertext, all it sees is opaque bytes, and that is the property I had to preserve no matter what feature anyone asked for.

In practice messaging apps do not encrypt every message with your long-term public key directly. They derive short-lived session keys from long-term keys via a handshake. That is where protocols start to matter, and where I had to make calls that have stuck with UmbrellaX since the first commit.

The Signal Protocol, in one page

The Signal Protocol stitches together three pieces: X3DH (Extended Triple Diffie-Hellman) for the initial handshake, the Double Ratchet for the ongoing message stream, and pre-keys for asynchronous contact. I genuinely admire the design even though I did not pick it for UmbrellaX.

When you first message a contact, X3DH runs a three-step Diffie-Hellman exchange that mixes your long-term key with a one-time key the recipient uploaded in advance. The result is a shared secret both sides compute but no observer can. From that secret, the Double Ratchet starts producing a sequence of per-message keys. Every time a message is sent, the key ratchets forward; every time a reply arrives, the key ratchets again from the other side. Each individual message has its own key. Each key is discarded as soon as it has been used.

Forward secrecy falls out of this. If an attacker seizes my device today, the per-message keys that encrypted yesterday’s messages are already gone. Post-compromise security falls out too: even if an attacker read your keys an hour ago, after the next ratchet they cannot read what you are sending right now. I have done audit work where exactly this property mattered, and watching it work is genuinely lovely.

The Signal Protocol has been in production since 2013. I respect Moxie’s work and I will say plainly: for one-to-one messaging it is still the gold standard.

MLS, in one page

MLS stands for Messaging Layer Security. It is an IETF standard, formalised in RFC 9420, published after roughly six years of design at the IETF. The named design goals are explicit: groups as a first-class primitive, efficient membership changes, formal-verification amenability. Those goals matched my Tier-D threat-model framing exactly, and that is when I committed to MLS for UmbrellaX.

The core data structure is a binary tree of keys, not a chain. Each leaf is a group member; each internal node is a combined key derived from its two children. When a member is added, a new leaf goes in and the tree updates the nodes along the path to the root. That update is O(log N) in key operations where N is the group size. When a member is removed, the path is updated with fresh keys, and the removed member cannot compute any node because they no longer hold the leaf key.

Forward secrecy and post-compromise security work by rotating the tree’s root key; every commit in the group produces a new root and destroys the previous one. I walked through the math on a 200,000-member tree and the numbers still hold, which is the property I needed for protest-coordination groups at the scale I am sizing for.

Why MLS and not the Signal Protocol for a new messenger? Three reasons I went MLS from day one.

Groups are first-class. The Signal Protocol handles groups by layering pairwise Signal sessions; key operations grow O(N) per membership change. At 100+ members it starts to matter. At 500+ it defines the user experience. At 200k it would be impossible.

Formal verification. MLS was designed for model-checking. Large portions, including the key-schedule and the commit flow, have been mechanically verified. The Signal Protocol got component analyses but the protocol grew up in the field. For a Tier-D threat model I want the math nailed down before the first user lands.

Interoperability. MLS is a standard. A client implementing MLS correctly can talk to any other MLS client. I plan to keep that open-spec posture as my implementation evolves.

I chose MLS from day one. Signal has been publicly exploring MLS migration since 2023, and I think they are right to do that, but they are doing it after the fact.

Noise Protocol Framework, briefly

Noise is not itself a messenger protocol; it is a construction kit for secure channel protocols. Specifications like “Noise_XX” or “Noise_IK” describe specific handshake patterns with formally-defined properties. WireGuard uses a Noise pattern. I use one for certain internal service-to-service channels inside UmbrellaX, because it is the cleanest formally-described handshake I know for a transport-layer problem.

If you are building a new cryptographic system today, I think Noise is often the right starting point for the transport handshake. For group messaging on top, MLS is the right layer.

What E2EE does not protect

This is where most explainers drop off, and I think it is the most important part of the whole article.

E2EE protects message content in transit. It does not protect several other things, and a serious reader should know which.

Metadata. The server still sees who talked to whom, at what time, and how often. On mobile networks it also sees IP address and carrier. Modern messengers mitigate some of this with techniques like Sealed Sender and private contact discovery, but not all. I minimise metadata on UmbrellaX through sealed-sender equivalents plus a message-padding layer, and I route through my own 167-microservice infrastructure rather than third-party cloud providers. Signal does similar work on its own architecture. Telegram does almost none of this, and I think that gap is undersold in most reviews.

A device that has already been unlocked. E2EE keys live on your device. If an attacker has your unlocked phone, they can read everything. Device-based security depends on the device being under your control, and that is true for me as much as anyone else.

An invited group member. If you add an attacker to a group chat, that attacker will read the group. E2EE protects against servers, not against humans you let in.

Key substitution by a malicious server. If the server hands your contact a fake public key, your contact will encrypt messages to that fake key and the server can read them. This is the key-distribution problem, and it is the failure mode I worry about most because it does not require breaking any cryptographic primitive. Modern messengers defend against it through safety-number verification (Signal), key transparency logs (WhatsApp, Keybase historically, UmbrellaX), or trust-on-first-use with explicit re-verification.

Your own backup decisions. If you enable “cloud history without end-to-end key protection”, which some messengers offer for convenience, the server gets a key to your history. UmbrellaX’s cloud history keeps keys on-device by default. If you choose to enable cloud-key recovery, I make sure you make that trade-off consciously, with a 5-of-3 Shamir Secret Sharing layout in custody mode so no single party (including me) holds enough fragments to recover anything.

Post-quantum: what changes and when

Classical E2EE relies on elliptic-curve Diffie-Hellman or RSA. Both will fail if a sufficiently large quantum computer ever exists. Estimates put a cryptographically-relevant quantum computer somewhere between ten and thirty years away. The precise date matters less than “before the useful lifetime of messages I am asking my users to send today”, and I spent two months on the question before committing to a design.

NIST finalised a set of post-quantum algorithms in 2024, principally ML-KEM (based on Kyber) for key agreement and ML-DSA (based on Dilithium) for signatures. These are not quantum-proof in any hypothetical sense; they are resistant to known quantum algorithms, which is the strongest claim cryptographers make.

MLS extensions for post-quantum key agreement exist and are shipping in 2026. UmbrellaX runs PQ-hardened MLS by default. I picked a hybrid X25519 plus ML-KEM-768 design specifically because pure post-quantum still spooks me on key sizes and field history, and I would rather an attacker have to break both classical and lattice cryptography to break a session. Signal has announced PQ work on its roadmap and may have shipped partial support by the time you read this.

The model to internalise: if you send a sensitive message today on a classical-only messenger, and a state-level adversary archives every ciphertext, and a quantum computer arrives in fifteen years, your message is readable in fifteen years. Hybrid PQ/classical agreement removes that timer. That is the timer I refused to leave on for my users.

How UmbrellaX implements E2EE

Every chat on UmbrellaX is end-to-end encrypted by default. No “secret mode” toggle. No “cloud chat” alternative the server can read. One-to-one, group, voice, video: same model. I built it that way deliberately, and I would not ship anything else.

My cryptographic stack: MLS as the core group-messaging protocol, with an ML-KEM-768 hybrid for post-quantum key agreement on top. Long-term identity keys are Ed25519 signatures; short-term session keys are derived through the MLS key schedule. Key transparency logs make identity-key changes publicly verifiable so a malicious server cannot quietly swap a user’s key. Sealed-sender-equivalent metadata protection sits on top of that. Message padding to fixed-size buckets reduces traffic analysis.

Device recovery uses a recovery key the user stores off-device or splits across devices using a 5-of-3 Shamir scheme in custody mode. If all devices are lost and no quorum of recovery fragments is available, chat history cannot be restored. That is the honest trade-off E2EE demands and I am not going to dress it up.

I publish the full design of the Umbrella Protocol separately under a source-available licence so independent cryptographers can read, audit and implement compatible clients. The specification itself is open under Creative Commons so anyone can build on it. I think that openness is part of what makes a Tier-D claim defensible at all.

What a reader should actually do

If you are picking a messenger for sensitive conversation in 2026, match the tool to your threat model, not to brand name alone. I am not neutral on this, but the framework here works whoever you end up choosing.

If your threat model is “don’t let my employer read my DMs” or “don’t let my provider sell my data”, any mainstream E2EE messenger is enough: Signal, UmbrellaX, WhatsApp, iMessage between Apple devices. I would not lose sleep over the choice at that level.

If your threat model is “don’t let a state archive my content today and decrypt it in fifteen years”, you need post-quantum hardening. In 2026 that means UmbrellaX, Signal if its PQ rollout completes, or a specialist tool. I think the harvest-now-decrypt-later threat is real and I designed for it.

If your threat model is “don’t let a government compel my provider”, jurisdiction matters. Signal is US, a 501(c)(3). Telegram is UAE with Pavel Durov indicted in France in 2024. UmbrellaX is Kazakhstan, outside the Five Eyes. I picked Kazakhstan deliberately, not because it is a civil-liberties utopia (it is not) but because it sits outside US compellability.

If your threat model is “the server itself might be lying to me”, key transparency matters. UmbrellaX and WhatsApp have key transparency in production. Signal uses safety numbers verified out-of-band, which is honest engineering but a heavier UX tax.

E2EE is not magic. It is a concrete set of cryptographic techniques with concrete boundaries. Understand the boundaries, and the tool does what it is supposed to do.

I’m Kirill Abramov, founder and CEO of UmbrellaX TOO, a privacy-first messenger company registered in Kazakhstan, outside the Five Eyes alliance. I designed UmbrellaX’s cryptographic stack on MLS plus post-quantum hardening, and I write about end-to-end encryption, post-quantum cryptography, and the regulatory pressure on private communication. More about my work and why I run UmbrellaX from Kazakhstan: umbrellax.io/about.