Nine_Layers_Of_Denial

Nine Layers of Denial

You want your recipient to be able to forge your messages. That sentence is the entire cryptographic argument of this chapter, and most readers will fight it before they accept it.

Key Takeaways

• SimpleX implements nine distinct cryptographic and protocol defense layers in series — redundancy, not paranoia.
• Repudiation (deniability) is the design's signature property: the recipient can forge messages, so neither party can prove to a third party who said what.
• Post-quantum key exchange is added on every ratchet step as of v5.6 (March 2024) — Streamlined NTRU Prime hybridized with the Signal double ratchet.
• Private message routing (v5.8, June 2024) introduces 2-hop onion routing with four nested encryption layers that hide sender IP from recipient's relay and vice versa.
• Message padding to a fixed block size — only SimpleX, Cwtch, and the now-defunct Pond do this. Defeats size-based traffic analysis, the most powerful remaining side channel.

---

Here is the unfashionable claim I want to defend in this chapter: the cryptographic centerpiece of SimpleX is not the encryption itself. It is the *deniability* of the encryption. A reader who comes to this material expecting "unbreakable math protects you" will miss what is actually load-bearing. The math is good — but the math protects the *content*. The architecture protects the *fact that you communicated at all*. And the property that closes the loop is that a third party cannot prove, from the cryptography alone, who said what.

To a layperson that sounds like a bug. To the cypherpunk tradition that produced Signal, OTR, and now SimpleX, it is the point. The reason matters, and I will spend most of this chapter on it.

The nine layers, enumerated

The GLOSSARY (docs/GLOSSARY.md) lists the defense-in-depth explicitly. I reproduce and compress:

1. Double ratchet E2EE (Signal algorithm) per conversation — forward secrecy + post-compromise security. 2. Additional NaCl cryptobox E2EE layer per queue — redundancy against future multi-server routing and TLS compromise. 3. Inner server-to-recipient NaCl layer — no shared ciphertext between send and receive paths. 4. TLS 1.2/1.3 only with restricted ciphers (CHACHA20POLY1305_SHA256, Ed25519/Ed448, Curve25519/Curve448). 5. Out-of-band TLS certificate verification — MITM mitigation on the relay. 6. TLS-unique channel binding signed per-queue ephemeral key — replay defense. 7. Multi-layer message padding to fixed block size — size-based traffic analysis defeated. 8. Out-of-band key exchange via one-time invitation links/QR — MITM mitigation on client-client. 9. Manual and planned automatic queue rotation — long-term traffic-analysis defeat.

I want to flag layer 7 because it is the most under-discussed and the most consequential for ordinary users. Fixed-block-size padding is what kills size correlation. If you and I exchange a 53-byte "yes" and the next message is 2 KB, a passive observer who can see message sizes learns something — they learn the second message is not a "yes." SimpleX pads every message to a fixed size regardless of payload. The v5.6 blog post (March 2024) notes that only SimpleX, Cwtch, and the now-defunct Pond do this among major messengers. Every other mainstream platform leaks message size as a free side channel.

Repudiation: the part that reads wrong

Open the v5.6 post (blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.md) and look at how the authors describe repudiation:

"The solution to that is well known to cryptographers — it is the quality of the encryption algorithms called 'repudiation', sometimes also called 'deniability'. This is the ability of the senders to plausibly deny having sent any messages, because cryptographic algorithms used to encrypt allow recipients forging these messages on their devices, so while the encryption proves authenticity of the message to the recipient, it cannot be used as a proof to any third party."

Read that twice. The cryptographic construction is *intentionally* designed so the recipient can manufacture a message indistinguishable from one I sent. The recipient knows the message is real (their end of the protocol authenticated it). A court, a journalist, a stalker with a warrant — none of them can distinguish a real message from a forged one because the cryptographic primitive does not commit to authorship in a third-party-verifiable way.

This is the opposite of what most users want from "secure messaging." Most users want a digital signature they can show a lawyer. The cryptographic tradition SimpleX inherits says: signatures in private communication are a weapon that eventually gets turned against the speaker. The 1996 Bernstein v. United States case (blog/20240314-...md line 51) is the foundational citation — DJB had to sue the US government to publish Snuffle in the first place because cryptographic code was classified as a munition. The cultural lineage that produced the protocol is the same one that produced the repudiation default. The default is not naive; it is the result of a thirty-year argument about who cryptography serves.

There is one footnote of honesty the protocol authors acknowledge: as of v5.6, signatures are still used when authorizing senders to the relay (server-side message authentication), not between clients. v5.7 was scheduled to close that gap. The trade-off is being made explicit in the documentation, which I will note is rare in this category of software.

Post-quantum on every ratchet step

In March 2024, SimpleX added post-quantum key exchange to the Signal double ratchet algorithm — on every step of the ratchet, not just at session establishment. The chosen primitive is Streamlined NTRU Prime, hybridized with the classical Curve448 handshake. The Apple PQ3 publication (security.apple.com/blog/imessage-pq3/) is cited in the same blog post as a reference point — meaning SimpleX's PQ integration predates or coincides with the highest-profile industry announcement of the same primitive family.

The threat model is "record now, decrypt later." An adversary captures ciphertext today; in ten years, a cryptographically relevant quantum computer exists; the adversary decrypts the historical traffic. Forward secrecy alone doesn't help — the captured ciphertext was encrypted under a session key derived from classical DH, and a quantum adversary breaks that DH. The defense is to refresh the key exchange material with a PQ-secure KEM at every ratchet step, so the captured ciphertext's decryption requires breaking both classical and PQ assumptions simultaneously.

This is real cryptography engineering. The Trail of Bits July 2024 review (blog/20241014-...md) examined the design specifically. I note it because a privacy-messaging project running its own PQ integration on the ratchet timeline is unusual; most projects defer to upstream library changes.

Private message routing: 2-hop onion

In June 2024, SimpleX shipped private message routing (blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.md). The design is 2-hop onion routing with four encryption layers between sender and recipient:

flowchart LR
    S[Sender client] -->|e2e| D[Destination relay]
    S -->|s2d NEW| F[Forwarding relay]
    F -->|f2d NEW| D
    D -->|d2r NEW| R[Recipient client]
    F -. cannot read .- S
    F -. cannot read .- R
    D -. cannot see sender IP .- F
    R -. cannot see forwarding hop .- F

What this defeats: a forwarding relay used to learn both sender IP and the destination relay's address. The destination relay used to learn the sender IP. After v5.8, neither party learns the other's network identity. The four encryption layers (e2e / s2d / f2d / d2r) are nested, not duplicated — each layer protects a different segment.

The design is opt-in (user toggles "Private message routing" in Network settings). From v6.0 it is enabled by default. The trade-off is throughput and battery; the protection is full IP unlinkability across the message path.

The honest residual

I do not want to leave the impression that nine layers means total security. The SECURITY.md (docs/SECURITY.md) explicitly excludes device-level attacks, physical side channels, and CPU/hardware flaws from the threat model. The GLOSSARY itself disclaims objectivity: "some definitions reflect this view." A motivated adversary with endpoint access — malware on your phone, a custom CPU interposer, a compromised supply chain — defeats every layer above. Cryptography is not magic; it is math against a network adversary. SimpleX's layers narrow the attack surface considerably; they do not eliminate the endpoint problem.

What the layers *do* eliminate is the most common failure mode in messaging privacy: the server-side correlation graph. The graph is gone because there is no graph at the server level — only disposable, unlinkable queues. The cryptographic layers ensure the content of the queues is opaque even if the server is compromised.

What I now believe

I came into this chapter skeptical that the cryptographic depth was more than marketing. Reading the protocol spec alongside the v5.6 post and the Trail of Bits July 2024 review moved me. Three specific things changed my assessment:

• Padding to fixed block size is a stronger privacy property than the encryption itself for the metadata-rich threat model SimpleX targets.
• Repudiation is not "weak crypto" — it is the cryptographic realization of "off the record" conversation, and it is the right default for private speech.
• PQ-on-every-ratchet-step is real engineering, not a roadmap promise, and it shipped before most peers had any PQ plan at all.

The defense is layered because the attack surface is layered. E03 looks at who is paying for this engineering and what is keeping them honest.

---

References:

• docs/GLOSSARY.md — defense-in-depth list and the repudiation definition.
• docs/SECURITY.md — threat model boundaries.
• blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.md — PQ-NTRU-Prime integration, padding analysis, and the Bernstein legal precedent.
• blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.md — four-layer onion routing.
• blog/20241014-simplex-network-v6-1-security-review-better-calls-user-experience.md — Trail of Bits July 2024 cryptographic review.