Encryption & Privacy Architecture

Goal: No Single Entity Can Read Messages

This is not just about E2E encryption — it's about ensuring that even metadata (who talks to whom, when, how often) is not observable by any single party.

Signal Protocol / Double Ratchet

The Signal Protocol is the gold standard for 1-to-1 encrypted messaging.

How the Double Ratchet works:

Two parties perform an initial key agreement (X3DH — Extended Triple Diffie-Hellman)
They derive a shared root key
For each message, a new message key is derived from the chain (KDF chain)
Periodically, a new Diffie-Hellman ratchet step mixes in fresh keying material
Result: every message is encrypted with a unique key

Security properties:

Forward secrecy: Compromising current keys does not reveal past messages
Post-compromise security: After a key compromise, security is restored once a new DH ratchet step occurs
Break-in recovery: Even if an attacker has current state, they lose access after the next DH exchange

Adaptation for offline/proximity use:

X3DH normally requires a server to store "prekey bundles" for asynchronous key exchange
In a proximity-first system, the initial key exchange happens in person (NFC/QR) — no prekey server needed
The Double Ratchet then operates over whatever transport is available (BLE, WiFi, Tor)
This is actually more secure than Signal's online model because the initial exchange has no man-in-the-middle risk

MLS (Messaging Layer Security) — RFC 9420

MLS is an IETF standard for efficient group encryption. It solves Signal's scalability problem for groups.

How MLS works:

Uses a ratchet tree (binary tree of DH keys) instead of pairwise ratchets
Adding/removing members is O(log n) instead of O(n)
Provides forward secrecy and post-compromise security for groups
Designed for groups of thousands (though our use case is likely smaller)

Relevance to our use case:

Group chats / shared social feeds could use MLS
Works well with the physical-first model: adding a member to a group requires physical introduction
MLS "proposals" (add/remove/update) could be distributed via gossip rather than a central server

Metadata Protection

Encryption protects content but not metadata. For structural privacy, we need to protect:

1. Social graph (who knows whom):

In offline-only mode: the social graph is inherently private — only you and your contact know about the relationship
If online relay is used: onion routing (Tor) or mixnets prevent the relay from learning who communicates with whom
Never store the social graph on any server, even encrypted

2. Communication patterns (who talks when):

Offline mode: No network observer exists — communication only happens at physical proximity
Online mode: Use constant-rate traffic (cover traffic / padding) to prevent traffic analysis
Store-and-forward via Tor hidden services: relay cannot correlate sender and receiver

3. Device identity / tracking:

BLE MAC rotation (already standard on modern devices)
Rotate BLE advertisement content to prevent long-term tracking
No persistent identifiers in any broadcast — only reveal identity after mutual authentication

The Never-Online Privacy Advantage

When a device never connects to the internet, the attack surface collapses dramatically:

Threat                    | Online Mode          | Offline-Only
--------------------------|----------------------|------------------
Mass surveillance         | Possible (ISP, CDN)  | Impossible
Traffic analysis          | Possible (netflow)   | Impossible
Server compromise         | Risk (if relay used) | No server exists
IP-based tracking         | Possible             | No IP addresses
Legal compulsion (server) | Risk                 | Nothing to compel
Social graph extraction   | Risk (metadata)      | Only via physical observation
Message interception      | Risk (if E2E broken) | Requires physical proximity

This table shows why "never online" should be the default mode, with online as an opt-in that users choose knowing these tradeoffs.

Post-Quantum Considerations

Quantum computers threaten current public-key cryptography. For a forward-looking design:

Signal's PQXDH: Already integrates post-quantum key exchange (CRYSTALS-Kyber) into the X3DH handshake
Signal's SPQR ("Triple Ratchet"): Adds a post-quantum ratchet layer on top of the Double Ratchet (announced October 2025)
Recommendation: Use hybrid classical + post-quantum key exchange from the start. The NFC tap can exchange both Ed25519 and ML-KEM (Kyber) public keys — the extra ~1200 bytes is well within NFC capacity

These keys are part of the identity bundle defined in the Feed Format Spec.

Storage Encryption: Data at Rest

Protecting data on the device (and on relay servers) is as important as protecting data in transit. The following tools are relevant for our deployment scenarios.

Disk & Volume Encryption

VeraCrypt — Cross-platform disk encryption. Creates encrypted containers (file-based) or full volume encryption. Supports hidden volumes for plausible deniability (a second encrypted volume exists inside the outer one; the password you give reveals only the decoy). Relevant for relay server storage volumes and desktop research machines.

Shufflecake — Linux kernel-level plausible deniability tool, a modern replacement for the discontinued TrueCrypt hidden-volume concept. Creates up to 15 hidden filesystems on the same block device, each protected by a different passphrase. Unlike VeraCrypt, Shufflecake operates at the block device level, making forensic detection significantly harder.

Cryptomator — File-by-file encryption for cloud storage. Transparent AES-SIV encryption of each file before upload. Open source and well-audited (Cure53, 2021). Relevant for research document storage and relay server config backup to untrusted cloud hosts.

Picocrypt — Minimal single-file encryption tool using XChaCha20-Poly1305 and Argon2id for key derivation. No installation required. Useful for encrypting individual files (model weights, key material exports, backup archives) for air-gapped transfer via USB.

Relevance to Our System

Use case                        Recommended tool
──────────────────────────────  ────────────────────────────────
Relay server storage volume     VeraCrypt (Linux, automated mount)
                                or LUKS (Linux dm-crypt, standard)
Relay server cloud backup       Cryptomator (transparent cloud E2E)
Air-gapped key export / USB     Picocrypt (single-file, no install)
Forensic-sensitive research     Shufflecake (plausible deniability)
Phone app local database        SQLCipher (AES-256-CBC on SQLite)

LUKS (Linux Unified Key Setup) via dm-crypt is the standard choice for full-disk encryption on Raspberry Pi relay servers — it is integrated into the Linux kernel and adds negligible overhead. The relay server setup should include LUKS-encrypted partitions for the message store, key registry, and any AI model caches that might contain indirectly identifying data.

SimpleX Queue Model: Structural Metadata Protection

The SimpleX Chat protocol (covered in Existing Protocols) uses a queue-based identity model that offers insights for our metadata protection layer worth documenting here in detail.

The Problem with Keypair Identity

Every other E2E encrypted system — Signal, Session, Matrix, Briar — uses a persistent keypair as the user's global identity. The public key (or a derivative like a phone number hash) serves as a stable identifier. This creates:

A linkable identity across all contacts and conversations
A target for traffic analysis: if the server sees many senders writing to the same keypair, the social graph is partially exposed
A permanent identifier that can be correlated across surveillance datasets

SimpleX's Solution: Per-Contact Anonymous Queues

Instead of a global identity, SimpleX creates a separate queue for each contact relationship:

Alice wants to message Bob:
  1. Bob creates a receive queue (Q_B) on a relay server
  2. Bob shares Q_B's address with Alice (via QR code, link, etc.)
  3. Alice sends messages to Q_B — the server sees only Q_B, not Alice's identity
  4. Alice also creates a receive queue (Q_A) and shares it with Bob
  5. Bob sends replies to Q_A — the server sees only Q_A
  6. Each queue is rotated periodically (new queue, same relationship)

What the relay server sees:
  - Messages arriving at queue addresses (opaque identifiers)
  - No link between Q_A and Q_B (they are on different or same servers, independently)
  - No user account, no global ID, no social graph

Application to Our Design

Our system can adapt this model for the offline case:

During the NFC/QR tap, Alice and Bob exchange ephemeral queue descriptors — random identifiers for where to deliver messages when the other party is encountered over BLE
These queue IDs are per-relationship and rotated periodically, preventing long-term tracking even by a malicious relay
When used with Tor for the online mode, the queue model + onion routing means the relay sees neither who sends nor who receives — only that a queue exists

The NFC payload (currently planned at ~150 bytes) can accommodate a SimpleX-style queue descriptor alongside the existing key material with minimal additional space.

Recommended Encryption Stack

┌──────────────────────────────────────────┐
│           Message Encryption              │
│  1-to-1: Double Ratchet (Signal)         │
│  Groups: MLS (RFC 9420)                  │
├──────────────────────────────────────────┤
│           Key Exchange                    │
│  In-person: NFC/QR → X3DH (+ PQXDH)    │
│  Ratcheting: DH + post-quantum ratchet  │
├──────────────────────────────────────────┤
│           Identity                        │
│  Ed25519 signing keypair                 │
│  X25519 DH keypair                       │
│  ML-KEM-768 post-quantum keypair         │
├──────────────────────────────────────────┤
│           Metadata Protection             │
│  Offline: inherent (no network)          │
│  Online: Tor hidden services + padding   │
└──────────────────────────────────────────┘

Updates (2025–2026)

NIST Post-Quantum Standards Finalized (August 2024)

NIST officially published three FIPS post-quantum standards on 13 August 2024:

FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, formerly CRYSTALS-Kyber). Three parameter sets: ML-KEM-512, ML-KEM-768, ML-KEM-1024.
FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium).
FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Standard).

Our recommended identity bundle (Ed25519 + X25519 + ML-KEM-768) now maps directly to ratified federal standards. ML-KEM-768 is the FIPS 203 mid-security parameter set and is the variant Signal chose for SPQR (see below). Falcon (FN-DSA) and HQC are still in standardisation and not yet ready for production integration.

Signal SPQR and the Triple Ratchet (October 2025)

Signal published the Sparse Post-Quantum Ratchet (SPQR) on 2 October 2025. This is the production release of work presented at Eurocrypt 2025 and USENIX Security 2025.

Key facts for our stack:

SPQR uses ML-KEM-768 (FIPS 203). The encapsulation key is 1,184 bytes; ciphertext is 1,088 bytes — sized to fit NFC exchange alongside classical key material.
The Triple Ratchet is the combined protocol: Signal runs the Double Ratchet and SPQR in parallel, mixing their outputs through a KDF so an attacker must break both X25519 and ML-KEM-768.
Rollout is gradual with graceful downgrade for older clients.

⚠ Clarification on existing content: The existing page describes SPQR as "announced October 2025." This is accurate — the blog post date is 2 October 2025 — but rollout was still in progress as of that date, not yet complete. The page's recommended stack (Double Ratchet + SPQR ratchet, ML-KEM-768 identity key) remains valid and is confirmed by Signal's production choice.

OpenMLS — Active Development Through 2026

OpenMLS (Rust, maintained by Phoenix R&D and Cryspen) reached v0.8.1 on 13 February 2026, confirming the library is actively maintained and RFC 9420-conformant. AWS Labs' mls-rs provides an independent Rust implementation with 100% RFC 9420 conformance and full support for all default credential, proposal, and extension types. Neither library has shipped post-quantum ciphersuites as of early 2026; the MLS working group has not yet standardised PQ extensions. Groups in our design can safely adopt OpenMLS or mls-rs for the MLS layer while the PQ-MLS extension matures separately.

MLS Gaining Production Momentum

Google committed to using MLS for Android Messages, and active integration work is underway for Android and Firefox (Open Technology Fund). This broad industry adoption validates RFC 9420 as the right group-key-establishment target for our design and increases library maturity over time.

Mixnet and Metadata-Resistance Research

Katzenpost describes itself as the world's first post-quantum mixnet, integrating PQ cryptography for anonymous transport. Nym continues active development with a 2025 roadmap item to replace the Sphinx packet format with a lighter "Outfox" format for efficiency. Both projects confirm that mixnet-layer metadata protection is technically maturing, but independent reviews note that mixnets introduce latency that constrains real-time use. Our current recommendation (Tor + cover traffic for online mode; no network for offline mode) remains appropriate for a proximity-first app where online relay is already opt-in.