Generate
B runs ML-KEM-768 key generation inside its own Web Worker and shares only the public key.
Envelope v1 · ML-KEM-768 · NIST FIPS 203
Post-quantum encryption you can verify yourself.
LatticeLink seals messages between two agents with ML-KEM-768, HKDF-SHA-256 and AES-256-GCM, entirely inside your browser. Then it invites you to break it.
- Self-test
- running…
- Median seal
- —
- Median open
- —
- Servers involved
- 0
Live channel · this tab
A … ⇄ B …
- Sealed
- 0
- Verified
- 0
- Tampered
- 0
- Rejected
- 0
Built on open standards
NIST FIPS 203ML-KEM
IETF RFC 5869HKDF
NIST SP 800-38DAES-GCM
NIST FIPS 180-4SHA-256
NIST FIPS 197AES
W3C Web Cryptography APIbrowser crypto
WebAssemblylocal AI runtime
WebGPUon-device inference
01 Live trace
Every operation, in the open.
This console is not a recording. When it scrolls into view, your browser generates a key, seals a message, opens it, then attacks it three ways, and prints what actually happened, with the time each step took.
- Key generation and encapsulation from noble-post-quantum 0.7.1
- HKDF and AES-256-GCM from your browser’s built-in WebCrypto
- Three attacks, three refusals, and no plaintext released
live-trace · this tab
waiting
Timings measured in this tab · lines paced for reading
02 Try to break it
Change one bit. Watch it fail.
Below is a real envelope, sealed a moment ago to a key that exists only inside a worker on this page. Click any byte to flip its lowest bit. The worker runs the real decryption on the altered copy.
- Ciphertext
- the encrypted message itself
- Tag
- 16 bytes that authenticate everything
- Nonce
- 12 random bytes, fresh per message
- KEM ciphertext
- 1,088 bytes only the recipient can open
Waiting for the envelope
Every attempt starts from the untouched envelope.
03 The protocol
Four steps from a public key to a verified message.
Standardized primitives, composed in the open and executed entirely on the two parties’ own devices.
Encapsulate
A encapsulates to B’s public key, producing a fresh 32-byte shared secret and a 1,088-byte KEM ciphertext.
Seal
HKDF-SHA-256 derives a single-use AES-256 key. AES-256-GCM encrypts the message and authenticates every header field.
Verify
B parses strictly, decapsulates and checks the tag. On any failure it releases nothing, not a single byte.
One message, end to end. Only B can derive the AES key; everything on the channel is public.
1,184bytes
ML-KEM-768 public key
1,088bytes
KEM ciphertext, fresh for every message
128bits
authentication tag over the message and every header
0servers
ever see your keys or your message
04 Why now
Harvest now, decrypt later.
Encrypted traffic can be recorded today and stored until a large enough quantum computer exists. Shor’s algorithm would then break RSA and elliptic-curve key exchange, the public-key cryptography behind most secure connections today.
No one has publicly demonstrated a quantum computer capable of that. The risk is to data with a long shelf life, which is exposed the moment it is captured. Post-quantum key encapsulation such as ML-KEM is designed to resist the attack.
- 1994
Peter Shor publishes a quantum algorithm that factors integers and computes discrete logarithms efficiently.
- Dec 2016
NIST opens its call for post-quantum public-key algorithms.
- Jul 2022
NIST selects CRYSTALS-Kyber for standardization as its key-encapsulation mechanism.
- Aug 2024
NIST publishes FIPS 203. Kyber becomes ML-KEM.
- Nov 2024
NIST’s draft transition plan, IR 8547, proposes deprecating quantum-vulnerable public-key algorithms after 2030 and disallowing them after 2035.
- Today
You can run ML-KEM-768 in this browser tab, and check every step yourself.
05 Envelope v1
One open, versioned format.
A strict JSON envelope with explicit algorithm identifiers. Every header field is bound into the AES-GCM tag as associated data, so changing any of it is detected.
- Unknown fields, versions and algorithms are rejected before any cryptography runs
- Canonical base64url only: exactly one valid encoding per envelope
- A published test vector that reproduces byte for byte
- An independent reference implementation, checked against the app in every build
envelope.json
sealed in this tab
Sealing a live envelope…Sealed moments ago by the self-test, to a key that existed only inside a worker on this page.
06 Isolation
The secret key has no way out.
Each agent runs in its own Web Worker. B’s secret key is created inside its worker, and the worker’s protocol has no request that returns it. It is never displayed, stored, exported, sent to A or shown to the AI.
Ephemeral by design
Keys live in memory only. Closing or refreshing the tab destroys them, and every envelope sealed to them becomes unopenable.
A strict content policy
The site’s Content-Security-Policy allows connections only to itself, plus Hugging Face for model files once you opt in to the AI.
Nothing to collect
No cookies, analytics, accounts or server-side processing. Messages and keys never reach a server, because there is none.
07 On-device intelligence
A local model that explains, and never decides.
An optional small language model drafts messages and explains results in plain English. It runs on your GPU through WebGPU, loads only when you ask, and never sees a key, a shared secret or an envelope.
- Model
- SmolLM2-360M-Instruct · Apache-2.0 · pinned revision
- Runtime
- Transformers.js 4.3.1 · ONNX Runtime Web, served from this site and integrity-checked
- Download
- About 275 MB from Hugging Face, once, after you opt in
- Sees
- Your drafting request, or plain facts derived from public records
- Never sees
- Keys, shared secrets, envelopes or decrypted text
- Decides
- Nothing. Every verdict comes from the cryptography.
Internal tests, 10 October 2026, Chrome 154: over WebGPU on an NVIDIA RTX 4070 the model was ready in 32.5 s including the download and generated 34 to 79 tokens per second; on the CPU path it was ready in 49.6 s and generated 3.4 tokens per second. Small models make mistakes; every answer is labelled as live model output.
08 Security posture
Stated plainly.
Strong cryptography is necessary, not sufficient. This is exactly what a passing run demonstrates, and what it does not.
A passing run shows
- This implementation encrypts and decrypts your message with ML-KEM-768, HKDF-SHA-256 and AES-256-GCM, in your browser
- Every tested alteration (a flipped bit, an edited header, a wrong key, a malformed envelope) is detected, with no plaintext released
It does not show
- That the system is secure in general, or free of side channels and untested bugs
- That any quantum attack was attempted or defeated
- Who sent a message. There is no sender authentication
Audit status. ML-KEM is provided by noble-post-quantum 0.7.1, which states that it has not been independently audited (it was self-audited at version 0.6.1 in April 2026). LatticeLink’s own code has not been externally reviewed. It is a research preview, not an audited secure messenger.
Read the security modelEvery build52 of 52 unit tests passed in this build
Every visitSix-check self-test in your browser
Implementationsnoble-post-quantum 0.7.1 + WebCrypto
Research preview
Don’t take our word for it.
Run the checks yourself.
It takes about a second, it runs entirely on your device, and every verdict comes from the cryptography.