We design for hostile networks, compromised infrastructure, and the possibility that today's traffic will be read later. Our approach is simple to state and demanding to maintain: strong defaults, minimal data, separated systems, and claims you can test.
Cryptography is one layer of security, not the whole practice. We try to make the safe path the normal path, remove data we do not need, and make the boundaries between systems visible enough to inspect.
Post-quantum key exchange and signatures are part of the connection rather than an expert-only switch. There is no quiet downgrade to an older cipher suite just to make a handshake look convenient.
We do not keep IP logs, vault contents in any form, or third-party analytics. Over Tor, the server receives an exit-node address instead of yours; the best data to protect is data that never arrives.
The Windows VM Manager keeps QEMU control local and access-controlled. Its shared folder is an explicit airlock that can be opened for a task and closed afterward, not a permanent bridge between host and guest.
We show the algorithms, explain what the client and server can see, and point to ways to check the result on the wire, through Tor's own circuit data, or by self-hosting. Trust should have an escape hatch.
Good-faith security reports are welcome. We would rather fix a claim in public than preserve a polished story that no longer matches the software.
We publish the attacks these controls do not stop: compromised devices, traffic correlation, metadata, what the server can still read, and why calls are refused over Tor. A clear limit is part of the protection.
These are NIST's standardised post-quantum algorithms, not pre-standard drafts or in-house designs. There is no legacy cipher suite to negotiate down to.
| Purpose | Algorithm | Why this one |
|---|---|---|
| Key exchange | ML-KEM-1024; X25519 + ML-KEM-768 for TLS | FIPS 203. ML-KEM-1024 seals every message, mail and file. The TLS session underneath uses the X25519 + ML-KEM-768 hybrid, secure while either half holds. Neither can be recovered from recorded traffic by a future quantum computer. |
| Signatures | ML-DSA-87 | FIPS 204, highest parameter set. Authenticates servers and clients so a recorded handshake cannot be forged later. |
| Bulk encryption | AES-256-GCM | Symmetric ciphers are far less affected by quantum attack than public-key ones; 256-bit keys retain a large margin. |
| Password hashing | Argon2 | Memory-hard, so custom hardware buys an attacker much less than it would against a fast hash. |
| Transport | QUIC | Encrypted from the first packet, with per-stream isolation and no separate unprotected handshake to observe. |
Post-quantum cryptography has two separate jobs, and almost every deployed system does one of them. The distinction is worth understanding before you take anyone's word for "quantum-safe", including ours.
| PQ key exchange | PQ signatures | Routable over Tor | Self-hostable | |
|---|---|---|---|---|
| QuantumPost | Yes — ML-KEM | Yes — ML-DSA-87 | Yes | Yes |
| Signal | Hybrid (PQXDH) | Classical | Via Orbot | No |
| iMessage | Hybrid (PQ3) | Classical | No | No |
| Classical | Classical | No | No |
A broken key exchange is retroactive: recover the key years later and the recorded conversation opens. A broken signature is not — it lets an attacker impersonate someone from that point on, but it does not unlock anything already sent.
So prioritising key exchange is a defensible engineering decision, not negligence, and the teams above are not careless. It is the harvest-now threat they are answering, and they are answering it.
Signature migration is slow and painful — it touches every certificate and every trust decision in a system. Doing it at the start costs us bandwidth on every handshake today, and costs us a migration we will never have to run later.
It is the more expensive choice and we think it is the right one. You can disagree; the point is that the table above tells you what you are actually getting.
Everything above is a claim, and a security claim you cannot check is worth roughly nothing. These are the ways to confirm it without taking our word for any of it — including the one that is genuinely hard for us to fake.
Point Wireshark at the QUIC port and watch a connection start. This is the check we would least be able to fake, because post-quantum credentials are enormous and it shows.
An ML-DSA-87 signature is roughly 4.6 KB and its public key roughly 2.6 KB. The classical equivalent — an Ed25519 signature — is 64 bytes. A post-quantum handshake is visibly, unmistakably larger, and it takes several round trips to get through QUIC's anti-amplification limit because of it. If we were quietly using classical crypto, the handshake would be small and fast, and you would see that immediately.
The algorithms are printed on the sign-in screen, before you log in — ML-KEM-1024 · ML-DSA-87 · AES-256-GCM. Not buried in an about box, and not a different list from the one on this page.
The client's Tor tab does not report our numbers. It reads Tor's own control port and shows you the guard, middle and exit relays it actually built, their countries and fingerprints, and live bandwidth. Cross-check any of those relays against the public Tor consensus — if they do not match, we are lying to you.
The server is self-hostable, which is the strongest form of this: you do not have to believe anything about what we log, because you are the one running it. Point your own client at your own server and inspect every byte between them.
Connect with Tor on, then look at the connection from the server side. The address it sees is a Tor exit node, not you — verifiable against the public list of exits. That is the network enforcing it, not our policy promising it.
The Secure Browser's capability matrix marks only one category of ten as measured, and each claim names what was observed and what has not been run yet. Test any of them against the shipped build — the page tells you precisely what it does and does not stand behind.
You can route QuantumPost through Tor so that our servers never learn your address. This matters for a specific reason: it moves the guarantee from something we promise to something the network enforces.
Your IP address, from us. We see a Tor exit node, which is not you. There is nothing for us to log, disclose, or lose in a breach, because the information never arrives.
It does not hide our address — the server is public either way. It does not hide from your network that you are using Tor. And it is slower, because your traffic is taking three extra hops.
A privacy policy is a promise about data you hold. This is a description of data that is never written down in the first place, which is a stronger position for everyone — including us.
Connection addresses are not recorded. Over Tor we never receive yours at all.
Your vault and password entries are encrypted with keys derived on your device, and stay on it: they are files in the program's own folder, never uploaded. Your browser history, bookmarks and sessions live in an encrypted database (SQLCipher, AES-256).
No trackers in the client, and none on this website — it does not even load its fonts from anyone else. Nothing to share because nothing is collected.
Every one of these is true of the strongest systems in the world, not just this one. Anyone who tells you otherwise is selling something.
An adversary who can watch both ends of a connection at once can often match them by timing alone, whatever the encryption. No deployed network solves this, including Tor.
Encryption protects data in transit and at rest. It cannot protect a machine where someone else is already reading the screen or the keyboard.
Messages are encrypted. The fact that an account connected at a particular moment is inherent to any online service; Tor is the mitigation we offer for it.
Real-time calls need low latency, which Tor cannot provide. So while you are connected over Tor, the client refuses voice and video calls rather than letting them go around it. Text chat in voice and video rooms still works.
The vault and the password manager never leave your computer, so the server has no copy of them at all, encrypted or otherwise. Messages, mail, files and calls do pass through it, sealed end to end. Feed posts, comments and polls, profiles, the wiki and Knowledge Base, and who is friends with whom are not yet: the server stores them where it can read them. Moving each one behind encryption is the roadmap.
Feed photos and videos the client has fetched are cached on your device without their own encryption, for now. Encrypting that cache is on the roadmap.