Summary
Within those limits, the design goal is narrow and testable. Only the holder of the recipient’s secret key can read a sealed message, and any change to an envelope is detected before a single byte of plaintext is released.
Threat model
The channel between the agents is assumed hostile. This table states what each kind of adversary can and cannot achieve.
| Adversary can | Outcome | Status |
|---|---|---|
| Read envelopes in transit | Learns the message length and the recipient’s key fingerprint, not the content | By design |
| Change any byte of an envelope | Detected by the AES-GCM tag or the strict parser; no plaintext is released | Tested at every ciphertext and tag position |
| Open an envelope with a different secret key | Implicit rejection, then authentication failure; nothing released | Tested |
| Replay an old envelope | Not detected. Version 1 has no replay protection | Known limitation |
| Substitute their own public key before A imports it | Can read the messages unless A compares fingerprints with B over a trusted channel | Trust assumption |
| Send B a message claiming to be A | Possible. There is no sender authentication | Known limitation |
| Record traffic now and attack it later with a quantum computer | ML-KEM is designed to resist known quantum attacks. Nothing here can test that claim | Assumption on ML-KEM |
| Measure timing or other side channels | Not defended. The ML-KEM implementation is pure JavaScript and does not claim constant-time execution | Known limitation |
| Control the device or browser of either agent | Full compromise | Out of scope |
The trust assumption
Encryption protects a message only for whoever holds the secret key matching the public key it was sealed to. If an attacker substitutes their own public key, A will seal the message to the attacker. A fingerprint does not make a key trustworthy just by existing, because an attacker’s key has a perfectly valid fingerprint too.
Fingerprints help only when A compares all 64 hex digits with the fingerprint B reports over a channel A already trusts, such as in person or on a voice call. In the single-page demo both agents share one tab, so the comparison is shown automatically. In two-browser mode, the comparison is the visitor’s responsibility, and the interface asks for it explicitly.
Key handling
- Secret keys are generated inside a dedicated Web Worker from the browser’s cryptographically secure random number generator, and never leave it.
- No request in the worker protocol returns a secret key. Keys are never logged, displayed, stored, exported, sent to the other agent or given to the AI.
- Keys are ephemeral. Closing or refreshing the tab destroys them, after which envelopes sealed to them can never be opened.
- Shared secrets are wiped immediately after key derivation, and derived AES keys are non-extractable. In JavaScript, wiping memory is best effort only.
Implementation assurance
Checked on 9 October 2026.
| Component | Provides | Assurance |
|---|---|---|
| @noble/post-quantum 0.7.1 | ML-KEM-768 | Its README states it has not been independently audited. Version 0.6.1 was self-audited in April 2026, and a reproducibility study against NIST vectors (not an audit) covered 0.7.0. It does not claim constant-time execution. |
| Browser WebCrypto | SHA-256, HKDF, AES-GCM, random numbers | Built into the browser and maintained by its vendor. |
| LatticeLink code | Envelope format, parsing, worker isolation | Not externally reviewed. 52 of 52 unit tests passed in this build, plus an independent reference implementation and browser end-to-end tests. |
| Transformers.js 4.3.1 and the model | Optional drafting and explanations | Not security-relevant by design. Isolated in its own worker, it receives no secrets and cannot affect a verdict. |
Platform controls
- A strict Content-Security-Policy. Scripts come only from this site, there are no inline scripts or styles, and network access is limited to this site plus Hugging Face for the opt-in model download.
- Cross-origin isolation (COOP and COEP), no-referrer and nosniff headers, and a Permissions-Policy that disables the camera, microphone, geolocation, payment and USB.
- Served over HTTPS, with a Strict-Transport-Security header that tells browsers to use only HTTPS for this site for a year after the first visit. Without HTTPS, browsers withhold WebCrypto and cross-origin isolation, and the demo would not run.
- No cookies, analytics, accounts or third-party scripts. The AI runtime is self-hosted and integrity-checked before use.
Known limitations
- No sender authentication, replay protection or forward secrecy beyond the per-message encapsulation.
- Message length and the recipient’s fingerprint are visible to anyone who sees an envelope.
- ML-KEM is used alone, without a classical algorithm alongside it as a hedge.
- Pure-JavaScript ML-KEM with no constant-time guarantee. Browsers deliberately coarsen the timers used for measurements.
- The small language model can be wrong. Its output is labelled and never trusted for any decision.
Reporting a vulnerability
A dedicated security contact has not been published for this research preview yet. Until one is, do not use LatticeLink to protect information that matters.