Lattice Lattice

Security.

A short page summarising what Lattice defends against and what it doesn't, with links to the full threat model, audit reports, and disclosure policy. The detail lives in the white papers and the technical specifications; this page is the index.

The 60-second summary.

   What is protected:
   ──────────────────
     ✓ Message contents in transit  (ChaCha20-Poly1305 AEAD)
     ✓ Message contents at rest     (per-cell AEAD in the local DB)
     ✓ Identity authenticity        (Ed25519 signatures, hybrid PQ session)
     ✓ Forward secrecy              (Noise XX ratchet + per-message nonce)
     ✓ Post-compromise security     (MLS for groups, double ratchet 1:1)
     ✓ Quantum-resistance           (ML-KEM-768 mixed into every session)
     ✓ Sender / recipient unlinking (sealed-sender tags, padding buckets)
     ✓ Recipient privacy from relays(onion-wrapping for high-threat sends)

   What is not protected:
   ──────────────────────
     ✗ Endpoint compromise          (rooted phone wins; out of scope)
     ✗ User error                   (lost seed = lost identity, by design)
     ✗ Radio-presence detection     (BLE adverts are visible to anyone in
                                     range — your *presence* on the mesh
                                     is detectable, your *content* is not)
     ✗ Global passive observer
       with traffic confirmation    (Tor doesn't either)
     ✗ Denial-of-service jamming    (no consumer app can defend against
                                     deliberate radio jamming)

Threat model — three tiers.

T1 — Local passive radio observer.

An adversary in BLE / Wi-Fi range capturing every byte you transmit. Defences: ChaCha20-Poly1305 AEAD per packet (RFC 8439), padding to 256/512/1024/2048 bucket sizes (defeats length-correlation attacks), sealed-sender recipient tags (relays can't tell who packets are for), optional Poisson cover-traffic emission (uncorrelates user activity from wire activity). Limit: your presence as a Lattice user is detectable from the BLE service UUID we advertise. We do not pretend otherwise; that's the cost of working without a server.

T2 — Local active radio adversary.

Same range as T1 plus the ability to inject and modify packets. Defences: AEAD authentication tags reject any modification, time-windowed Bloom dedupe rejects replays, sliding-window nonce protection at the session layer rejects out-of-order replays inside a session, Ed25519 signatures on every introduction / vote / burn command. Limit: an active adversary in your local airwave can deny service by jamming. No application can prevent radio jamming on consumer phones.

T3 — Network-level adversary (state-level resources, traffic confirmation).

An adversary with access to multiple physical observation points, doing classical traffic-confirmation analysis (timing, volume, correlation). Defences: cover traffic in high-threat mode, optional 3-layer onion wrapping with X25519 per layer, optional Tor v3 bridge for the bridged-internet path. Limit: a sufficiently capable adversary can do traffic confirmation against any messenger. Tor admits this. We admit it. The defence against this class is not running the app, or running it inside a much larger anonymity set than we currently provide.

What is explicitly out of scope.

The full threat model with every defence cited to a specific source file: WP-01 — Threat Model.

Cryptography.

Standards we conform to or use, in alphabetical order:

Full mapping with citations and implementation crate names: Specifications.

Audit history.

Pre-v1.0 audit is being commissioned with one of Trail of Bits, Cure53, or Latacora. Scope: cryptography, identity layer, Lattice Invite protocol, MLS integration. Timeline: completes before v1.0.0.

Post-launch audit cadence:

Reports will be published in full unless they contain unfixed critical issues, in which case publication is delayed until fix. Public advisory log will live at lattice.fyi/advisories.

Reporting a vulnerability.

Please drop a note in our Matrix room, encrypted to our PGP key (public key, key fingerprint posted on this page once it's generated). We acknowledge receipt within 72 hours and commit to a fix or documented mitigation within 90 days for critical issues. Researchers who follow the policy are publicly credited (or remain anonymous by request) and are explicitly safe-harboured against legal action by us for good-faith research.

Full policy: /security-disclosure.

What you can do as a researcher.