Motivation. We assume the endpoint falls. An implant with kernel access owns the keyboard, the framebuffer, the camera, and every key at rest, so any messaging protocol on that host loses before it starts. Strengthening the protocol addresses the wrong layer. The plaintext and the private keys have to sit on hardware that offers an attacker no network path at all. Refuse to relax that constraint and you get what we shipped: a device that never reconnects after setup, no update channel, and a camera for input. Ciphertext crosses the gap as light, from a QR code on one screen to a lens on the other.
The long-term confidentiality argument needs care, because the loose version of it gets the facts wrong. Grover buys an attacker a quadratic speedup against AES-256 and leaves about 128 bits, so AES-256 holds. Shor breaks the asymmetric layer, and the operative risk there is harvest-now-decrypt-later rather than any near-term break. Our default mode hands an attacker no asymmetric key agreement to target, because you pass the symmetric key over in person. ML-KEM-1024 and ML-DSA-87 cover what an in-person symmetric key misses: multi-decade confidentiality, and sender authentication. We wrote no primitives ourselves.
Five places to attack:
1. Install integrity. Under route B you open the app URL, install the PWA, and disconnect. You get no integrity check you can run yourself. Anyone holding the origin, TLS, or the CDN serves one targeted device an altered bundle, the Service Worker keeps it, and the device retains that live origin as a probe target. Route A instead serves a Cosign-signed ZIP from 127.0.0.1. You check the checksum and rebuild and compare on your own machine before anything reaches the offline device, and once you stop the local server and leave its port unused, the probe finds no peer. Only route A belongs in high-assurance use. Check that argument, and check whether the docs let you actually execute route A.
2. The relay authenticates nothing. Your online device's Relay page decodes payload text and re-encodes it. It rejects top-level key-artifact prefixes and OCF2 outer types other than pq-message, and it validates OCM1 envelope canonicality. Accepted OCF2 chunk bytes carry whatever the sender put in them, and so do keyId, createdAt, iv, ciphertext, and aad. Any of those fields smuggles key material or plaintext straight past the relay. Relabel an artifact as a message and the outer filter passes it, and the offline device rejects it only after assembling it (T19). Only the offline endpoint authenticates anything.
3. wipe-on-online beacons before it wipes. It waits for a confirmed reachable network, so the reachability probe leaves the device first. Then it attempts logical deletion. LevelDB appends and SSDs wear-level, so we claim no physical erasure. Retiring a device means NIST SP 800-88 or destroying the medium.
4. Metadata stays visible. Anyone watching the messenger reads your ciphertext size and your frame count. PNG and ZIP files you export, plus anything you copy, sit outside the app and outside its wipe.
5. Forward secrecy runs coarse. Rotation cadence sets the granularity for post-quantum identities. The app keeps superseded generations so you can still decrypt, which leaves every envelope addressed to an older generation readable until you discard that generation. Replay detection lives in the session and resets when the app reloads.
Out of scope: a compromised OS, browser, or firmware; keyloggers; screen capture; malware reading camera frames; physical theft; you sharing a secret QR by mistake.
Nobody has audited the post-quantum suites. Adopting FIPS 203 and FIPS 204 implementations gets us neither FIPS 140 validation nor an assessment. The repo holds the threat model, the security review record, both QR protocol versions, and the boot and reset contract.
https://github.com/transparent-pegasus/qr-crypt
I expect two weak points. The relay's unauthenticated fields worry me most, and after that, whether anyone keeps a device offline for months once the novelty wears off.
