Closing every exit but one: how QR Crypt's decisions converge on T21

transparent-pegasus — Thu, 30 Jul 2026 10:28:49 +0000

QR Crypt encrypts text on a device you disconnect during setup and never reconnect. Ciphertext leaves as a QR code on the screen, and a second device carries it to an ordinary messenger.

The threat model has 22 rows. One of them, T21, has a countermeasure column that says the hop has effectively none. I want to trace how the project got there on purpose, because T21 sits at the end of a chain of decisions that each closed a different way for the application to hand a secret to a third party. Reading the repository in that order makes the architecture legible in a way the feature list does not.

The guarantee has a precondition, and the precondition sets the work

Section 2 of docs/security/threat-model.md scopes what the app promises. The application does not intentionally transmit plaintext, private keys, or symmetric keys off the device. Then comes the clause that governs everything after it: this guarantee assumes that the installed code is authentic.

That clause splits the design problem in two.

For the shipped app, the job is subtractive. Find every route by which the code as built could move a secret outward, and close it. Each closure is a decision with a date and a consequence.

For an app that is not the shipped app, no closure inside the code helps. Counterfeit code cooperates with none of it.

Do the first job completely and the second half becomes the whole remaining risk. That is T21, and the project reaches it by working through the first job one exit at a time.

Exit 1: the network

The app makes no external API calls. connect-src 'self' arrives as a response header from public/_headers, and production builds also inject the supported directives as a meta CSP fallback. frame-ancestors stays header-only because browsers ignore it in meta. No analytics, no logging, no error-reporting SDK, no external fonts, no CDN.

Three same-origin request kinds survive: fetching the PWA and its static assets, GET /reachability-sentinel.txt as the destructive probe that gates wipe-on-online, and a recurring HEAD /manifest.webmanifest?reach=… display probe. None of them carries user data or relay payload.

Two refinements in the verification checklist show where the obvious version of this rule leaks.

The first: an allowlist by method and path is insufficient. An allowed static GET can carry a payload in its query string. So the e2e assertions bind every allowed request to a fixed set of query keys, and any request carrying a key beyond the two named probes fails.

The second is stated in the docs as a warning against a plausible regression. Same-origin is not a safety property by itself, because code that POSTed relay text to this same origin would still be same-origin. The gate checks what a request carries, not only where it goes.

The camera decoder got the same treatment. zxing-wasm ships its reader binary as a hashed same-origin asset that Workbox precaches, and a module-scope locateFile overrides the library's default CDN fetch. No CDN, no runtime network request.

Exit 2: storage and diagnostics

An app that writes a secret somewhere durable has moved it outward in a slower way, so the storage rule is absolute about one class of value: no frame-derived or OCM1-derived value reaches app-managed IndexedDB, localStorage, or CacheStorage.

localStorage runs on an allowlist of four keys: oc-theme, oc-lang, oc-offline-ack-pending, oc-online-tab. The values are constrained too. The acknowledgement marker holds the literal "1". The tab key holds top or relay and nothing else.

A maintainer requirement on 2026-07-24 removed in-app QR storage. There is no saved-QR feature and no qrArtifacts store. Ciphertext and key QR codes get on-screen display, an explicit PNG or ZIP export, and the clipboard. Plaintext persistence is forbidden in both localStorage and IndexedDB.

Then the quieter exits. Production builds never write plaintext, keys, or QR contents to the console. Errors use fixed i18n and AppError mappings and never interpolate raw input, frame metadata, transferId, hashes, or caught.message. An error string that echoed its input would be an egress path with a friendly name.

The verification checklist enumerates the sinks it searches after capture, copy, paste, playback, rejection, close, pagehide, and timeout. Request URLs including query names and values. Request header names and values. Request bodies. Every IndexedDB database's schema names, meaning database, object-store and index names and key paths, alongside its keys and values. CacheStorage metadata and bodies. localStorage. Console. window.onerror and unhandled rejections. Visible error text. document.title. location.href. History state.

One line in that checklist reads like scar tissue. A single marker set has to cover every sink, because a request oracle that searches fewer markers than the storage oracle is the hole the line exists to close. The storage oracle's self-test plants two markers, one as a typed-array value and one that appears only in an object-store name, and requires exactly those two matches.

Exit 3: the online surface

Closing egress inside the app does nothing if the app runs its sensitive features on a connected device, so a decision on 2026-07-22 removed that possibility. OnlineGate fail-closes encryption, decryption, key management, and settings while online. Online use covers installation and the clean-origin optical relay, and nothing else.

The interesting part is what happens to a device that still holds secrets. A device carrying keys, post-quantum identity rows, or a Vault key takes the block-and-wipe path instead of the relay path. The relay feature therefore creates no incentive to bring a key-holding device online, which closes the social hole rather than the technical one.

Relay eligibility requires a completed sensitive-store scan proving absence, and it fails closed when the scan is indeterminate. The offline-to-online transition fires TransientClear, which drops plaintext, decryption results, and result payloads at once.

The docs disclose what this does not establish. A clean-origin check is a current logical-absence result under a completed scan, so it proves neither historical non-use nor physical erasure. A second tab writing a key during a relay session is a documented race against a stale eligibility signal.

Exit 4: the update path

On 2026-07-22 a commit reads feat: remove SW update features.

An update channel needs the origin to stay reachable. Keeping one would mean every installed device retains a live endpoint it is designed to contact, which is an exit by definition. Deleting the channel costs real usability, and deviations.md records the cost: a new version means sanitizing the device and installing fresh.

Exit 5: narrowing what can run at all

Code paths that exist can be reached. Several decisions cut the reachable surface rather than defending it.

On 2026-07-23 the active policy narrowed to maximum: ML-KEM-1024 and ML-DSA-87 only. The wire contract still carries four suites, but the balanced family (768/65) exists as reserved types and suite codes, and the operational boundary rejects it as UNSUPPORTED_ALGORITHM before any cryptographic processing. The project declines to implement it even for interoperability testing.

RSA went further. Key creation and decryption are gone, with no decrypt-only compatibility retained, and schema validation rejects non-A256GCM OCM1 messages. The OCP1 and RSA-OAEP-3072 vocabulary still parses so old records load, and it cannot be operated. The docs state the price without hedging: a non-extractable RSA private key cannot be rescued, so ciphertext of that kind is unrecoverable.

Then the configuration hole. VITE_ENABLE_RSA is retired and rejected, and its presence in the environment now fails validation at application startup rather than being normalized away. The note that follows is the kind of thing most projects leave out. The rejection is a startup check and not a build check, so a production build carrying a stale value still succeeds and embeds it, and that build then fails for every user instead of failing in CI. They wrote down which end of the pipeline catches it.

Allocation got bounded too, under T20. The v2 receiver accepts at most 128 frames of 1,000 bytes, so 128,000 artifact bytes. A bare-payload paste caps at 170,672 characters with a second 128,000-byte check after decoding. Canonical CBOR separately caps one map at 8 entries, the decoded value at 13 total entries, keys at 18 UTF-8 bytes, and text at 300 UTF-8 bytes, because a byte cap alone bounds neither entry count nor retained heap. Decoding uses null-prototype maps and keeps no process-lifetime cache of attacker-supplied keys.

When closing a hole would open a bigger one

F-02, found on 2026-07-28, is the decision I would show anyone arguing that security work means adding controls.

The finding was real. A recipient got no signal that the same ciphertext had already been accepted, and nothing refused a reused authenticated message ID carrying different ciphertext.

The fix shipped as a session-scoped receipt cache. One module-local map lives in each loaded window's JavaScript realm, bounded, evicting oldest first. A matching ciphertext hash raises a flag behind an explicit reveal, and a reused message ID gets refused as MESSAGE_ID_REUSED. Reload clears it, and other tabs never see it.

Cross-session detection would work better, and the project refused to build it. Persisting a receipt means writing a frame-derived or OCM1-derived value, which breaks the invariant from Exit 2, contradicts the clean-origin boot gate's premise, and would fail the verification gate on purpose. Closing the replay hole by that route would open a storage exit.

So the stronger control stays unbuilt, filed as an open security-design decision, with the work it would require spelled out: device-keyed opaque tags instead of a public ciphertext hash, ownership moved inside the boot controller, and matching spec edits. Conversation IDs, monotonic sequence numbers, hash chains, and adding a message ID to the AES v1 format sit in the same pile.

The relay: hardened, and declared untrusted

The online relay is the one place where the design deliberately lets attacker-influenced bytes pass through a connected device, so T19 documents exactly how far the hardening reaches.

The hop enforces a two-kind allowlist: canonical OCF2: strings whose untrusted outer header declares pq-message, or one canonical OCM1: message, never both in one transfer. The OCM1 path decodes the whole envelope and requires a byte-for-byte canonical re-encode to reproduce the input. Top-level OCK1: and OCP1: prefixes and disallowed OCF2 outer types get rejected.

Then the limits, stated by the project rather than discovered by a reader. That equality check establishes structural canonicality and nothing else. The hop performs no completed-artifact hash check, no AEAD or signature verification, and no decryption. Accepted OCF2 chunk bytes carry whatever the sender put in them, and so does every sender-controlled OCM1 field: keyId, createdAt, iv, ciphertext, aad. A public artifact relabelled as a message passes the outer filter and gets rejected only after the offline device assembles it. Relaying OCM1 also exposes the whole v1 envelope from one QR, including a 22-character keyId that stays stable per symmetric key and works as a linkability handle across every message under it.

Authentication happens at the offline endpoint or it does not happen.

What is left is T21

Now put the pieces together from the attacker's side.

The app makes no request that carries a payload. It writes no frame-derived value to storage. It interpolates nothing into an error string. It runs no sensitive feature while online, and a key-holding device that goes online gets wiped rather than relayed. It has no update channel to contact. Its unreachable algorithm paths are unreachable, and its configuration cannot re-enable them.

Every one of those closures assumes the code doing the work is the code that was built. Remove that assumption and T21 is what you get.

A counterfeit app on the offline device embeds keys or plaintext inside something shaped like ciphertext, displays it as OCF2: frames or one OCM1: message, and relies on you and your own online device to carry it out. The relay cannot authenticate opaque bytes, so it accepts them. The countermeasure column says effectively none, and points at T19 for the checks a compromised sender still satisfies.

The capacity is estimated rather than waved at: up to 128,000 bytes across an OCF2 frame set, or 2,953 characters in a single OCM1. frameCount and totalByteLength are visible in every outer frame, and the payload bytes are opaque, so nobody watching the transfer can separate real ciphertext from exfiltration.

T21 is the complement of the guarantee's precondition. Every other exit the application provides has an owner and a closure. This one requires the application to have been replaced, which is why no closure inside the application reaches it.

Which makes the install route the entire guarantee

T21 ends by naming its own dependency. Any claim that plaintext never reaches a third party rests entirely on installation integrity, and that is why the install route decision determines the overall guarantee.

Route B: open the app URL, install the PWA, disconnect. The receiving user can perform no integrity check. Anyone holding the origin, its TLS, or its CDN serves one targeted device a modified bundle, the Service Worker keeps it, and the device retains that origin as a reachable target.

Route A, the default for high assurance: download a Cosign-signed ZIP, verify signature and checksum, validate the archive container before extraction, rebuild from source and compare independently in a way that accounts for every archive member, then serve from http://127.0.0.1 and install from there. Stop the local server and no origin remains to reach.

The nation-state-security note states the position plainly: route A is the intended path, and the project accepts that route B can be tampered with.

F-01, from the same 2026-07-28 review, is the finding that made this route usable. The README carried a partial Route A procedure while the archive's INSTALL.txt was the only self-contained copy that actually reaches the offline device, which made the mandatory independent rebuild-and-compare easy to understate. The complete procedure now lives in its own document, and both READMEs keep a summary and a link.

Release evidence grew to match: an archive-internal SHA256SUMS.files covering every other ZIP member, fixed clean-checkout rebuild instructions, and a CI gate that compares two production builds' sorted file sets and per-file hashes in one runner.

And then the limit on all of it, in the project's own words rather than a reviewer's. The CI gate establishes same-environment determinism only, so environment-independent reproducibility stays unverified. Cosign attests which workflow built from which commit, not that the source produced the binary. An attacker controlling the CI environment can publish a correctly signed backdoor, and only an independent rebuild comparison detects it. Which is why the rebuild-and-compare step in Route A is marked mandatory rather than recommended.

Three origin rules finish the boundary. A browser origin comes from scheme, host, and port alone, and this local deployment has neither TLS nor host authentication, so localhost and 127.0.0.1 count as different origins. Serve anything else on that host and port later and it gets same-origin access to the stored keys and the Vault key, where a non-extractable key still decrypts through crypto.subtle. Change the port after installation and the app becomes a different origin that cannot reach its own data.

What "only" means here, and what it does not

The convergence above covers one class of risk: paths where the application itself moves a secret to a third party. In that class, T21 is what remains after every other exit was closed by a dated decision.

Three other classes sit outside it, and conflating them would overstate the result.

Declared non-goals. Compromise of the OS, browser, or firmware. Keyloggers, screen recording, screenshots. Malware capturing camera frames. Supply-chain compromise at first install or reinstall. Physical theft. A user sharing a secret QR by mistake. Key loss through browser data deletion. These sit outside by declaration, because the attacker owns something the app cannot reach.

Residual confidentiality risk that is not T21. Optical duplication at the moment a key QR is displayed (T3). The app's inability to establish that the user compared a fingerprint against the intended person rather than an attacker-supplied channel (T6). Malicious code that runs first on the same origin using the Vault key, a known Web Crypto boundary (T13). Superseded post-quantum generations staying decryptable until explicitly discarded (T14). A valid signature meaning only that it verified against a stored public key (T15).

Detection coverage and availability. Replay detection resetting on reload and losing entries to eviction (T2, F-02). Assembly no longer catching a single changed chunk that still decodes as canonical CBOR of the declared type (T16). The allocation ceilings under T20, which the docs classify as an availability and local-memory residual rather than a confidentiality one.

Two more limits belong here. Wipe performs best-effort logical deletion, and physical erasure is not claimed, so retirement means NIST SP 800-88 or destroying the medium. And no independent third-party audit has happened: security-review.md calls that an external blocker, records that release-approved has not been reached, and says outright that self-authored documents close nothing.

Read with those boundaries in place, the claim is narrower than "only one risk" and more useful. Every exit the application could provide has a named owner, a dated decision, and a test that fails if someone reopens it. The one that survives requires the application to be something other than what was built, and the project routes its entire assurance argument through the install procedure for exactly that reason.

Repository: https://github.com/transparent-pegasus/qr-crypt

For the primary sources: docs/security/threat-model.md §2 for the guarantee and its precondition, rows T19 through T21 for the relay and the residual, docs/develop/deviations.md for the dated decisions, and docs/develop/install-route-a/README.md for the procedure the argument depends on.

DEV Community: transparent-pegasus