Security
What protects the handover, and what it rests on.
Everything here is what the software actually does today. Where an assurance is missing, it says so on this page rather than in a footnote.
Where the boundary is
"No server" is easy to say and easy to abuse, so here is the precise version: file content never reaches us. Buying a licence and, for enterprise deployments, device enrolment and revocation do use our infrastructure.
Cryptography
Session
X25519 + HKDF
The two devices agree a key through the optical channel itself. Nothing is exchanged over a network, and the key exists only for that transfer.
Content
AES-256-GCM
The file is sealed before the first frame is displayed. A camera pointed at the wrong screen, or a photograph of it, yields ciphertext.
Evidence
Ed25519 / ES256
Dispatch and delivery are signed over a fixed byte layout, so a record cannot be re-interpreted later. The enterprise wire uses P-256 with canonical low-S signatures.
Two codes are derived from the session with separate labels: six digits and five drawn symbols. The operator compares them on both screens. That comparison is what defends against a screen or camera placed in the middle — and it only works if a person actually does it.
The evidence model
Dispatch record
The sender signs the content hash together with the work order, classification and target system.
Delivery receipt
The receiver verifies the content against the hash and signs that it arrived intact.
Approval chain
Optional. Produced, reviewed, released — each link signed over the previous one, so the order is provable and removing a link breaks the chain.
Audit ledger
Entries are hash-chained locally, so a deleted entry is visible as a gap.
Offline verification
An Apache-2.0 tool checks all of it without contacting us, with no account and no network.
Current status — read this before procurement
| Assurance | Status |
|---|---|
| Independent security audit of the protocol | Not completed |
| Published device matrix (speed, success rate on real hardware) | Not published |
| Hardware-backed device identity (TPM, StrongBox, App Attest) | Verifier implemented; production enrolment not shipped |
| Trusted timestamps (RFC 3161) | Implemented and verified offline; a timestamping authority is not yet contracted |
| Formal certification (Common Criteria and similar) | None, and none claimed |
| Vulnerability disclosure channel | Published in security.txt |
If a procurement checklist requires a certified product, we are not it yet, and we would rather you learn that here than three meetings in.
Reporting a vulnerability
Write to the address published in security.txt. We do not run a bug bounty; we do answer.