◇ Security model · slatewrap-v1
If a property cannot be verified by the user,
we do not claim it.
This page documents the cryptographic primitives, the threat model, the delivery-integrity assumptions, and the audit posture of the surfaces we operate. It is meant to be readable by an auditor, criticised by a researcher, and matched line-for-line against the running code.
§ 01 · Primitives
Concrete algorithms. Concrete parameters. No proprietary primitives.
* ML-KEM and ML-DSA are reserved for surfaces that genuinely require asymmetric behaviour. Qubble Chat (the first surface) does not currently use them; its key establishment is purely out-of-band, which gives it no Shor attack surface at all. Future surfaces that need public-key behaviour will adopt them in hybrid classical+PQ mode during transition, then PQ-only.
§ 02 · Threat model
What the design defends against — and what it does not.
Passive network observer
An adversary recording the wire sees ciphertext, message length, and routing metadata. The contents are AES-256-GCM-encrypted under a per-message subkey derived through the ratchet.
Compromised relay server
The server holds no decryption material. Compromise yields the same view as a passive observer — ciphertext and routing, no plaintext.
Harvest-now-decrypt-later (quantum)
Because no public-key handshake occurs on the wire, there is no asymmetric primitive for Shor to break. Captured ciphertexts remain AES-256, whose quantum security degrades to Grover's bound, not collapses.
Forward-secrecy compromise
The one-way ratchet discards prior chain keys after each step. Compromise of a current key does not yield prior message material.
Compromised endpoint device
If the user's device is compromised at the OS or browser level, no cryptographic protocol can protect the plaintext at rest in that environment. We minimise client-side persistence and expose enough of the ratchet state for users to detect anomalies, but a fully-compromised endpoint is out of scope.
Traffic-analysis & timing
The current design does not provide unobservable transport. An adversary with full network vantage can infer when communication occurs and approximate volume. Future surfaces may incorporate cover traffic; this one does not.
§ 03 · Delivery integrity
Browser-delivered cryptography is only as trustworthy as the binary the user actually runs.
We treat the integrity of the delivered code as part of the threat model, not as an assumption. The relevant guarantees on Qubble Chat are below; they will extend, with the same shape, to every surface we ship.
01 · WebAssembly isolation
Cryptographic operations execute inside a dedicated WASM module compiled from versioned source. The module exposes no host-side state machine that pure JS can spoof.
02 · Subresource integrity
Every script tag is loaded with an SRI hash. The browser refuses to execute a script whose body does not match the declared digest. CDN compromise alone cannot serve modified crypto.
03 · Reproducible build artefact
The shipped WASM is built from a pinned toolchain with deterministic flags. The build artefact's digest is published with every release; any auditor can rebuild and compare bit-for-bit.
§ 04 · Audit posture
Open invitation. Real channel. Adversarial review welcomed.
We do not publish self-praise. If you have looked at the primitives table above, or watched the ratchet step through in Qubble Chat, and you see a gap — bring it. We will respond to it on the record.
◇ Nothing on this page is a financial offering. The cryptographic claims are technical claims; they are stated so that they can be falsified.