Post-quantum keyslots
Hybrid ML-KEM-768 / 1024 keyslots - when, why, how.
Hybrid post-quantum keyslots add an ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203) layer on top of either passphrase or FIDO2 unlock. The wrap-KEK is derived from BOTH the classical secret AND the ML-KEM shared secret, so a quantum attacker who breaks one primitive still can't recover the MVK without the other.
Should you turn this on?
Yes if you're protecting data that needs to stay confidential past 2035 against an adversary who could (a) capture USB-HID traffic during your enrollment / unlock today, (b) store your encrypted vault file, and (c) wait for a cryptographically relevant quantum computer to arrive.
No if you don't have a way to keep the separate .kyber seed file on
trusted storage that's separate from the vault itself. Hybrid-PQ
without the seed file is the same as no PQ.
The two flavours
| Slot kind | Classical factor | PQ factor | Strength |
|---|---|---|---|
HybridPqKemPassphrase |
Argon2id passphrase | ML-KEM-768 | NIST cat 3 (~AES-192) |
HybridPqKem1024Passphrase |
Argon2id passphrase | ML-KEM-1024 | NIST cat 5 (~AES-256), eligible for ANSSI Eleve |
HybridPqKemFido2 |
FIDO2 hmac-secret | ML-KEM-768 | cat 3, hardware-backed |
HybridPqKem1024Fido2 |
FIDO2 hmac-secret | ML-KEM-1024 | cat 5, hardware-backed |
ML-KEM-1024 is overkill for most threat models. Pick it if your governing standard explicitly requires it (ANSSI Eleve, certain regulated industries) or if you want belt-and-suspenders.
Create a hybrid-PQ vault
# Generate a Kyber seed file. Save this to SEPARATE TRUSTED STORAGE
# (a USB stick you keep elsewhere, an HSM, etc.). Whoever has this
# file plus the vault passphrase can unlock the vault.
luksbox kyber-init /media/usb/my.kyber
# Create the vault, pointing at the seed file
luksbox create my-vault.lbx --kind hybrid-pq \
--pq-hybrid /media/usb/my.kyber
# For the FIDO2-hybrid variant
luksbox create my-vault.lbx --kind hybrid-pq-fido2 \
--pq-hybrid /media/usb/my.kyber
This produces three files:
my-vault.lbx- the vault itself (same byte shape as a non-PQ vault)my-vault.lbx.hybrid- sidecar with ML-KEM public key + ciphertext (next to the vault)/media/usb/my.kyber- the Kyber seed (passphrase-encrypted; keep elsewhere)
Open a hybrid-PQ vault
luksbox open my-vault.lbx -m /tmp/v --pq-hybrid /media/usb/my.kyber
# Prompts for the vault passphrase + the .kyber file's passphrase
# (which can be different).
For the FIDO2-hybrid variant: same command, plus a touch on your hardware key.
Threat-model context
The CTAP2 hmac-secret transport uses ECDH-P256 to encrypt the secret on the USB wire. ECDH-P256 is not post-quantum secure - a future CRQC could decrypt recorded USB exchanges and recover the hmac_secret. Pure-FIDO2 vaults are vulnerable to this attack; hybrid-PQ-FIDO2 vaults are not (the attacker would also need the Kyber seed file).
For the full threat model, see Threat model.
What about pure ML-KEM (no classical layer)?
Not offered. ML-KEM is a young primitive with limited public cryptanalysis history. Pairing it with battle-tested classical primitives (Argon2id, AES-256) means a future cryptanalytic break in either family doesn't break the vault. This is also the design guidance in NIST SP 800-208 and the broader PQ-transition consensus.
Implementation pointers
- ML-KEM crate: RustCrypto
ml-kem(FIPS 203) - Sidecar format: see
crates/luksbox-format/src/hybrid_sidecar.rs - Seed-file format: see
crates/luksbox-pq/src/seed_file.rs - KDF derivation:
KEK = HKDF-SHA256(salt, classical_kek || pq_shared_secret, "lbx:hybrid-kek/v1")