Hybrid post-quantum key wrapping, explained for non-cryptographers
Every key that protects a NomadVault file is locked twice, with a classical algorithm and a post-quantum one. Here is what that means, why both, and what it does not cover.
If you have read a vendor page lately you have probably seen the phrase “quantum-safe” or “post-quantum ready”. This article explains what it means at NomadVault.
The lock on the lock
Let’s start with how an encrypted file is stored. The file itself is scrambled with a strong symmetric cipher, AES-256-GCM. Symmetric means one key both locks and unlocks. That key is random, used for this one file only, and is called the file key.
Now the question becomes: where does the file key live? It cannot sit next to the file in plaintext, or anyone with the storage would have everything. So the file key is itself encrypted, so that only the people allowed to read the file can recover it. Cryptographers call that step key wrapping. The file key is wrapped, like a present, and only the recipient can open the wrapping.
Wrapping uses public-key cryptography. Each user has a key pair: a public key anyone may use to wrap something for them, and a private key that only they hold and that unwraps it. In NomadVault the private key is unlocked on your device by your password or passkey and never leaves it.
Everything that follows is about that wrapping step. The file encryption itself, AES-256, is not threatened by quantum computers in any practical way. The wrapping, however, is.
What a quantum computer changes
Public-key algorithms in use today, RSA and elliptic curves, rest on mathematical problems that ordinary computers cannot solve in any useful time: factoring very large numbers, or the elliptic-curve equivalent. In 1994 Peter Shor showed that a sufficiently large quantum computer solves exactly those problems quickly. Such a machine does not exist today. Estimates of when it might range from a decade to never.
The problem is that encrypted data does not expire. Anyone who can copy ciphertext today, a cloud provider, an intercepting network, a backup tape in the wrong hands, can keep it and wait. If a capable quantum computer arrives in 2040, every RSA-wrapped key captured in 2026 opens at once, and with it every file behind it. This is usually called harvest now, decrypt later. For documents that stay sensitive for decades, such as contracts, medical records, intellectual property or anything with a legal retention period, it is a present-day risk with a future payout.
Post-quantum algorithms, and why not simply switch
Over the past decade NIST, the US standards body, ran an open competition for public-key algorithms that resist quantum attacks. In August 2024 it published the first standards. The one used for wrapping keys is ML-KEM, formerly known as Kyber, standardised as FIPS 203. It rests on a different mathematical problem, lattices, for which no efficient quantum algorithm is known.
So why not replace RSA with ML-KEM and be done? Because ML-KEM is young. RSA has had almost fifty years of attack attempts; ML-KEM has had a few. A standard can be sound and still have an implementation flaw, or a weakness nobody has found yet. One of the finalists in the same competition, SIKE, was broken in 2022 on a laptop in an hour, after years of scrutiny. Betting everything on a new algorithm trades a known future risk for an unknown present one.
Hybrid: both locks, both keys required
The answer the industry has converged on, and the one NomadVault uses, is a hybrid. Each wrap uses RSA-4096 and ML-KEM-768, combined so that an attacker has to break both.
Here is the construction in plain words. To wrap a file key for you:
- Your device draws a fresh random secret and encrypts it with your RSA public key.
- It also runs ML-KEM against your ML-KEM public key, which produces a second secret and a small package only your ML-KEM private key can open.
- The two secrets are fed together into a key derivation function. The output is the actual wrapping key.
- The file key is encrypted under that wrapping key. The RSA ciphertext, the ML-KEM package and the wrapped file key are stored together.
To unwrap, your device needs both halves: the RSA private key to recover the first secret and the ML-KEM private key to recover the second. Missing either, the derivation produces garbage and the file key stays sealed. A quantum computer that breaks RSA still lacks the ML-KEM half. A future flaw in ML-KEM still leaves RSA intact. The attacker has to win twice.
This is not a NomadVault invention. It is the same reasoning behind hybrid TLS deployments by Chrome, Cloudflare and Apple’s iMessage upgrade. We applied it to the layer that matters most for stored documents: the keys that stay with the file for its lifetime.
Where it is applied
It would be easy to apply the hybrid wrap to file keys and stop. The point of a design is that it has no soft spots, so the same construction is used for every key that is sealed to someone in NomadVault:
- File keys sealed to a user or a group.
- Folder key bundles, which is how sharing a folder hands over access to everything inside it.
- Group keys sealed to each member.
- The search key, so even the blinded search index is behind the hybrid wrap.
- The optional escrow key your organisation can hold for recovery.
There is no legacy path. A recipient without an ML-KEM public key cannot be shared with, and older wrap formats are refused rather than quietly accepted. Every user who has registered since the hybrid design shipped has both key pairs generated in the browser at registration.
What it costs
Little. ML-KEM-768 is fast, and a wrapped key grows by about a kilobyte for the ML-KEM package. Wrapping happens once per key per recipient, not per byte of file, so a ten-gigabyte upload carries the same overhead as a one-page note. You will not notice it.
What it does not cover
This is the part most vendor pages leave out.
The network connection. The TLS connection between your browser and your tenant still uses classical key exchange. It carries only ciphertext and metadata, because the content was encrypted before it left your device, so a recorded TLS session opened by a future quantum computer would expose file sizes, timestamps and access patterns, never content.
Signatures. Share grants are signed with Ed25519, a classical signature algorithm, so that a compromised server cannot forge or redirect a share. Quantum computers threaten signatures too, but the threat is different: a signature has to be forged now to be useful, which requires the quantum computer to exist now. There is no harvest-now-forge-later. Post-quantum signatures, ML-DSA, are on the list for when their size and tooling mature.
Your device. None of this helps if the device that holds your private keys is compromised. A keylogger reads the file after you decrypt it, quantum or not. Passkeys, second factors and session limits reduce that risk; they do not remove it.
Metadata. The server knows how large your files are, when they changed and who has access. The hybrid wrap protects keys and content, not the shape of your data. We publish exactly what the server can see in the security overview.
Questions?
If this raises a question about your own documents, or your security team wants the full technical description behind this article, get in touch at hello@nomadvault.de.