Every file in HushOS is encrypted with a symmetric cipher, and symmetric ciphers with 256-bit keys are not what a quantum computer breaks. The place a quantum computer could hurt a service like this is sharing: when you share a folder with someone, your device seals that folder's key to their public key. If that seal rested on X25519 alone, a copy of the database taken today, plus a large enough quantum computer some years from now, would open every share ever made.
So it does not rest on X25519 alone. Shares between accounts are sealed with two key exchanges at once: an X25519 agreement, and an ML-KEM-768 encapsulation to a post-quantum key every identity carries. The two secrets are combined into one key, so the envelope opens only for someone who holds both private halves, and it stays shut unless both problems fall.
- The seal
- X25519 and ML-KEM-768 (FIPS 203) together, a 1160-byte envelope
- Your files
- XChaCha20-Poly1305 with 256-bit keys, which is not the weak point
- Your fingerprint
- The X25519 key alone: the post-quantum key is signed by your identity, not folded into the fingerprint
- What you do
- Nothing. Both keys are made at sign-up and used for every share
Why two, and not just the new one
ML-KEM is young. X25519 has two decades of attention behind it. Sealing to both means a flaw found in either one leaves the share shut, and the cost is a larger envelope that nobody ever sees.
Pins cover the second key
The server serves public keys, and a dishonest server could serve its own. Pins catch that, with a fingerprint two people compare over the X25519 key and the identity's signing key. The post-quantum key is vouched for by that signing key: the server refuses to store one without the signature, your device verifies it against the pinned signing key before using it, and a digest of it joins the pin. A different key served later is refused like any changed key, and a share is never sealed to X25519 alone, so withholding the post-quantum key gets a server nothing.
Updated October 2026: the fingerprint first covered only the X25519 key, which left a server room to pair the real X25519 key with a signing key and post-quantum key of its own. The words now cover both, and people added before are asked to compare them once more.
The same holds when you stop sharing with someone. Your device re-keys the folder and re-seals it to whoever remains, and it takes their keys through your pins, not from the server directly. A share to someone whose served key the pin refuses is left closed rather than sealed to a key you never vouched for.
The full construction is on the security page, and docs/drive-design.md in the repository fixes the byte layout.