Post-Quantum Key Management for Documents: Hybrid Sealing Under BSI TR-02102-1 (2026)

The German BSI, the French ANSSI and the Swiss Federal Office for Cybersecurity (BACS) all describe the same scenario: "harvest now, decrypt later". Encrypted data intercepted today could later be decrypted by a quantum computer. For documents that must remain confidential for ten years or more, the risk already exists today [1][2][3].

For documents in Nextcloud or openDesk, this concerns the keys more than the file content: anyone who intercepts a folder key while it is being handed over to a device or a server, and can later break that exchange, can read the entire folder. This article shows how a key hierarchy for documents is built, where classical cryptography becomes vulnerable, and how DuoKey SecureFolder seals the handover of folder keys in hybrid mode.

---

Table of Contents

1. What the Authorities Recommend
2. Where a Quantum Computer Attacks, and Where It Does Not
3. A Three-Level Key Hierarchy
4. Hybrid Sealing of a Folder Key
5. Protection Against Downgrade
6. Algorithms at a Glance
7. What Remains to Be Done?
8. Sources

---

What the Authorities Recommend

• BSI: since version 2026-01 of Technical Guideline TR-02102-1, the BSI recommends key exchange in hybrid mode for long-term protection of confidentiality, that is, classical combined with ML-KEM-768 or ML-KEM-1024, and recommends purely classical key exchange only until the end of 2031 [1].
• ANSSI: hybridization is necessary wherever post-quantum protection is relevant; security level 5 (ML-KEM-1024) is preferred, with level 3 (ML-KEM-768) as an alternative [2].
• BACS: post-quantum cryptography should be added to classical methods rather than replace them [3].

The common denominator: do not switch, combine. A hybrid scheme remains secure as long as either of the two schemes holds.

---

Where a Quantum Computer Attacks, and Where It Does Not

• Symmetric encryption (AES-256) is not threatened in practice by known quantum algorithms. File content in AES-256-GCM remains protected.
• Asymmetric key exchange (ECDH, RSA) is broken by a sufficiently large quantum computer. This is exactly the part that protects the handover of keys to devices and servers.

The weak point of document encryption is therefore where keys are distributed. That is where the post-quantum migration has to start.

---

A Three-Level Key Hierarchy

Figure 1. Key hierarchy.

1. KEK (key encryption key): stays in the HSM or vault the organization has chosen and never leaves it. Cockpit calls on it only to encrypt and decrypt. This meets the requirement of IT-Grundschutz module CON.1 to store long-lived keys outside the systems that use them [4].
2. Folder key: 256 bits, random, versioned, stored in Cockpit only in encrypted form under the KEK. It leaves Cockpit only sealed for a specific device or gateway.
3. File key: derived with HKDF-SHA256 from the folder key and a random file identifier, never stored. Content is encrypted in 64 KiB blocks with AES-256-GCM, and the header is authenticated with HMAC-SHA256.

A rotation creates a new version of the folder key: new writes use it, and older files remain readable.

---

Hybrid Sealing of a Folder Key

Figure 2. Hybrid sealing of a folder key for a device or a gateway.

Every device and every gateway registers two public keys: a P-256 key and an ML-KEM-768 encapsulation key (FIPS 203, 1184 bytes). The private keys never leave the device. For each release, Cockpit:

1. generates a fresh P-256 key pair and computes an ECDH secret with the device;
2. encapsulates a second secret for the device with ML-KEM-768;
3. derives a key from both secrets with HKDF-SHA-384, bound to a transcript of all public values, to the folder and to the key version;
4. uses it to encrypt the folder key with AES-256-GCM.

The result is a sealed block of 1218 bytes. The derived key remains secret as long as P-256 or ML-KEM-768 holds. A quantum computer that breaks P-256 fails against ML-KEM-768; an unexpected weakness in ML-KEM is covered by P-256. An intercepted block is useless, today and in the future.

SecureFolder thus applies the principle of the BSI, ANSSI and BACS to the handover of folder keys, with ML-KEM-768 (security level 3).

---

Protection Against Downgrade

A hybrid scheme is of little use if an attacker can make the other side fall back to the classical scheme. That is why:

• The gateway rejects any key that is not hybrid-sealed, regardless of what Cockpit's response states. An attempt to downgrade to P-256 alone is detected and rejected.
• Cockpit registers a gateway only with both of its public keys and never replaces them.
• Once registered, a device's ML-KEM-768 key is never replaced or removed.
• The version, the folder and the key version are bound into every seal as additional authenticated data.

---

Algorithms at a Glance

---

What Remains to Be Done?

Hybrid key handover is an important part, but not the whole migration:

• Transport: the TLS connections between the browser, Nextcloud, the gateway and Cockpit should also move to hybrid key exchange, as everywhere else in the infrastructure.
• Inventory: to know where purely classical schemes are still in use, you need a cryptographic inventory; the guide to ML-KEM key management shows how to go about it.
• Data lifetime: folders with documents that must remain confidential for more than ten years come first.

---

Sources

1. BSI, TR-02102-1, version 2026-01. bsi.bund.de
2. ANSSI, position paper on the migration to post-quantum cryptography (2022) and follow-up paper (2023). cyber.gouv.fr
3. BACS, technology assessment on quantum computing and post-quantum cryptography, December 2025. ncsc.admin.ch
4. BSI, IT-Grundschutz, module CON.1 Crypto Concept, 2023 edition. bsi.bund.de
5. NIST, FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. csrc.nist.gov

Sources checked 8 to 10 November 2026.