Pro · Local Agent Required
Quantum Courier
Hand a file directly to one recipient.
No public hosting. No third party. No copies.
Your most valuable work — the unreleased master, the draft manuscript, the hi-res photo to the gallery — doesn't belong on a CDN. Quantum Courier encrypts it directly to the recipient's public key and signs it with your post-quantum identity. The sealed blob travels however you want; only the recipient can open it.
The Courier needs the local Synergent Agent on the sender AND recipient. If you don't have it yet, the link above shows the install state.
How it works
Three steps. No accounts to create. No servers between you and the recipient.
Step 1
Recipient publishes an address
A small JSON dict with their ML-KEM-1024 public key and subject ID. They share it however they like — email, paste, QR. Bring-your-own out-of-band channel.
Step 2
Sender encrypts and signs locally
Your Synergent Agent generates a fresh ephemeral key, encrypts the payload with ML-KEM-1024 + AES-256-GCM, signs the envelope with FALCON-1024 + ML-DSA-87. Output: a single JSON blob.
Step 3
Recipient decrypts locally
They drop the blob into their own Quantum Courier. Their agent verifies your signature, decapsulates the KEM, decrypts the payload. They get the original bytes; you get nothing leaked.
What's under the hood
Every primitive is NIST-standard post-quantum. The whole stack holds up against a future quantum adversary running Shor and Grover at scale.
Key encapsulation
ML-KEM-1024
NIST FIPS-203 standard. 1024-bit security, lattice-based, resistant to Shor's algorithm. Each delivery uses a fresh ephemeral encapsulation — no key reuse across messages.
Authenticated encryption
AES-256-GCM
Symmetric AEAD bound to structured AAD (recipient, sender, timestamp). Modifying any binding field breaks decryption. 256-bit key derived via HKDF from the KEM shared secret.
Sender signature (NTRU lattice)
FALCON-1024
NIST FN-DSA (FIPS-206). NTRU-lattice PQ signature. Compact signatures (~1280 bytes), fast verification, resistant to known quantum cryptanalysis.
Sender signature (Module-LWE lattice)
ML-DSA-87
NIST FIPS-204. Module-LWE PQ signature. Co-signed with FALCON in a 2-of-2 envelope — both primitives must verify before a delivery is accepted.
Honest note on assumption diversity
FALCON and ML-DSA are two independent lattice signatures, not two cryptographic families. A deep advance against lattice assumptions could plausibly affect both. The 2-of-2 envelope is real defense in depth, but the assumption base is one lattice family.
High-assurance tier (coming v2.1a): add SPHINCS+ (NIST FIPS-205 SLH-DSA — hash-based) as a third signature. Hash-based security rests on entirely different math, so it survives a lattice break. That's the honest version of assumption-diverse redundancy. Standard-tier deliveries today are forward-compatible — the high-assurance envelope is additive.
What it's for
High-value work that should never sit on a public CDN, in a cloud bucket, or in an email attachment a scraper could index.
Film masters to the director
The final cut shouldn't go through Dropbox. Encrypt it directly to the director's courier address. Even if their laptop is later compromised, the master never sat on a third-party server.
Hi-res photos to the gallery
Photographer ships the print master to the curator. Encrypted in transit AND at rest until the gallery opens it. AI scrapers can't harvest what they can't reach.
Draft manuscript to the editor
The novel before publication. Hand it to the editor without it ever appearing in a cloud sync folder. If the editor's laptop is later stolen, the draft is encrypted at the file level — not just the disk.
Source code to the auditor
Pre-disclosure security audit. The codebase goes to the auditor directly. No GitHub upload, no email attachment that survives in Sent forever. Just one encrypted blob, audited and deleted.
What it does NOT hide
Cryptography is precise. Anything claimed beyond what the math actually proves is marketing, not engineering. Here's what Quantum Courier doesn't hide.
Identity of sender and recipient
Every delivery JSON contains the sender and recipient subject IDs in plaintext. A passive observer with the blob knows who sent it to whom. If that needs to be hidden, layer onion routing or a mixnet on top — Courier doesn't do that itself.
Approximate payload size
The ciphertext length leaks the plaintext size (modulo AEAD framing). For padding-resistant deliveries, pad payloads to known buckets before sealing.
Timestamp
When the delivery was sealed is in the blob. If timing is sensitive, that's a side-channel.
Delivery confirmation
The cryptography doesn't enforce a TTL or notify the sender when the recipient opens. That's storage and transport policy — bring your own.
Where it's headed
Today:bring-your-own agent on both sides. Power-user feature. Direct URL, no prominent UI promotion until there's a critical mass of installed agents.
Coming in Pro v2.1a: streamlined agent onboarding, hosted address discovery (opt-in) so you don't have to paste JSON, and Sealed Courier as a first-class part of the Pro tier alongside cloak-and-seal.
Eventually: integration with the Trained Responsibly registry — Couriered deliveries inherit license terms from the original seal, so a private hand-off to a lab still carries the "no-AI-training" flag.