Abstract
What Changed Since Version 2025-01
Compared with BSI TR-02102-1 Version 2025-01 dated January 31, 2025, the current Version 2026-01 dated January 23, 2026 introduces several concrete changes that affect migration planning and implementation design.
- Classical-only key agreement now has an explicit sunset: BSI recommends sole use of classic key agreement mechanisms only until December 31, 2031.
- For applications with very high protection requirements, the transition to quantum-safe mechanisms should be completed by December 31, 2030.
- Classical signature mechanisms are treated on a different transition horizon: BSI follows the European roadmap and recommends migration to quantum-safe signatures by the end of 2035.
- Hybridisation guidance was expanded: Version 2025-01 listed CatKDF only, while Version 2026-01 adds KeyCombine from NIST SP 800-227 as a recommended combination method.
- CatKDF guidance is more specific in Version 2026-01: BSI now explicitly recommends CatKDF with KMAC or HKDF and highlights input-format requirements when HKDF is used.
- Classical asymmetric key-agreement mechanisms are now framed as transition-only tools beyond 2031: after that point BSI recommends them only in combination with a quantum-safe KEM and the key-derivation guidance from Section 2.2.
- HQC is mentioned as a planned future addition after publication and review of the final standard, likely with parameter sets corresponding to NIST Security Strength Categories 3 and 5, but it is not yet part of the currently recommended baseline.
Key Points at a Glance
- BSI TR-02102-1 Version 2026-01 introduces explicit 2030 and 2031 migration milestones and updated hybrid key-combination guidance
- Our evaluation of examined implementations revealed multiple vulnerability patterns that could compromise BSI compliance
- Side-channel risk patterns were observed in randomness generation and error sampling routines in the reviewed sample
- Performance optimizations often introduced subtle security vulnerabilities
- Parameter validation was incomplete in several reviewed open-source implementations
- Our testing methodology identified documented issues and additional review findings in selected implementations
- ML-KEM vs X25519 was ~2× slower, whereas FrodoKEM was up to ~10× slower than ECDH in our tests
- FrodoKEM demonstrated strong side-channel resistance characteristics but with significantly higher performance costs
BSI TR-02102-1 Compliance Requirements
The BSI Technical Guideline TR-02102-1 Version 2026-01 updates the prior 2025 guidance with explicit migration deadlines, revised hybridisation guidance, and a clear end date for classical-only key agreement. BSI continues to target a minimum security level of 120 bits, continues to recommend hybrid deployment of quantum-safe and classical mechanisms during the transition period, and now states that sole use of classical key agreement is recommended only until December 31, 2031.
Approximate Security Levels by Algorithm (NIST Categories with AES-Equivalent Intuition)
Note: the AES references are an intuitive mapping to NIST Security Strength Categories, not a claim that post-quantum mechanisms have identical security properties to AES-192 or AES-256.
BSI emphasizes cryptographic agility so that implementations can absorb future algorithm changes. In Version 2026-01, FrodoKEM-976, FrodoKEM-1344, ML-KEM-768, ML-KEM-1024, and the BSI-listed Classic McEliece parameter sets remain the active quantum-safe KEM choices for long-term confidentiality at the targeted security levels. The report also notes that HQC is intended for future inclusion after publication and review of the final standard, likely with parameter sets corresponding to NIST Security Strength Categories 3 and 5, but it is not yet part of the currently recommended set.
Comparative Analysis of Post-Quantum KEM Schemes
| Algorithm | Public Key Size | Ciphertext Size | Key Gen (ms)* | Encaps (ms)* | Decaps (ms)* | Notes |
|---|---|---|---|---|---|---|
| ML-KEM-768 | 1,184 bytes | 1,088 bytes | ~0.08 | ~0.11 | ~0.10 | NIST standardized, BSI-recommended |
| ML-KEM-1024 | 1,568 bytes | 1,568 bytes | 0.12 | 0.15 | 0.14 | NIST standardized, BSI-recommended |
| FrodoKEM-976 | 15,632 bytes | 15,792 bytes | 1.50 | 1.80 | 1.70 | BSI-recommended conservative option |
| FrodoKEM-1344 | 21,520 bytes | 21,696 bytes | 2.80 | 3.20 | 3.10 | BSI-recommended conservative option |
| Classic-McEliece-6688128 | 1,044,992 bytes | 208 bytes | 185.00 | 0.05 | 6.50 | BSI-recommended conservative option |
*Performance measurements are indicative and based on our test environment (Intel Core i7-10700K at 3.8 GHz). Actual performance varies significantly based on implementation and hardware.
FrodoKEM size values refer to the standard FrodoKEM parameter sets, not eFrodoKEM variants. Classic McEliece sizes depend strongly on the selected parameter set; the row above uses Classic-McEliece-6688128 as one representative BSI-listed parameter set.
Critical Implementation Vulnerabilities
⚠️ Most Common Implementation Pitfalls
Our analysis of selected implementations across open-source projects, commercial products, and reference implementations revealed recurring implementation-risk patterns that can weaken security guarantees. These observations should be read as risk indicators for engineering review, not as ecosystem-wide statistics.
Methodology Note
Our review combined source-code inspection, known-answer-test checks, malformed-input tests, randomness-source review, and timing-variance screening on selected implementations. The sample was limited and version-specific; therefore, percentage-like terms below describe the reviewed sample only and should not be interpreted as statistically representative measurements of the wider post-quantum cryptography ecosystem.
Randomness Generation (Frequently Affected)
Many implementations we examined used predictable or insufficiently random sources for error sampling. BSI TR-02102-1 requires cryptographically secure randomness with substantial entropy. Common patterns we observed included using system time as seed, insufficient entropy collection during initialization, and predictable patterns in Gaussian sampling routines.
Side-Channel Leakage (largely affected)
Timing variations in polynomial multiplication and error sampling operations leaked secret information. Power analysis revealed key material through non-constant time operations. Memory access patterns exposed secret values through cache timing attacks, particularly in rejection sampling implementations.
Parameter Validation (nearly half affected)
Missing validation of public keys and ciphertexts enabled various attacks. Implementations failed to verify polynomial coefficient ranges, check ciphertext validity before decapsulation, and validate domain parameters against BSI specifications. This enabled malformed input attacks and potential key recovery.
Side-Channel Attack Resistance
FrodoKEM is often treated as a more conservative lattice-based option because it uses Learning With Errors over unstructured lattices rather than Module Learning With Errors. This can simplify some implementation-security arguments, but it does not provide automatic protection against timing, power, electromagnetic, cache, or fault attacks. Secure deployment still requires side-channel-resistant sampling, decapsulation, input handling, randomness generation, and key-erasure behavior.
BSI also motivates hybrid deployment partly because post-quantum mechanisms have not yet received the same long-term implementation and side-channel scrutiny as established classical mechanisms. For production systems, independent implementation review is therefore part of the security case, not an optional extra.
Migration Strategy and Best Practices
Successful migration to BSI-aligned post-quantum key establishment requires careful planning and systematic implementation. For high-assurance and public-sector systems, migration should be treated as a phased cryptographic modernization project rather than a simple algorithm replacement. Public reporting also indicates that the Bundeswehr wide-area network has been modernized with quantum-resistant encryption over a roughly 13,000-kilometer fiber network, but that deployment should be cited as an external example rather than treated as BSI benchmark data.
- Plan retirement of classical-only key agreement by December 31, 2031, and accelerate high-protection systems toward December 31, 2030
- Implement hybrid modes combining current public-key mechanisms with post-quantum KEMs, as recommended by BSI for the transition period
- Use CatKDF with KMAC or HKDF, or use KeyCombine as described by NIST SP 800-227, when combining key material from hybrid exchanges; bind algorithm identifiers, public keys, ciphertexts, and transcript context where required by the protocol design
- Deploy ML-KEM-768 or ML-KEM-1024 for the standardized ML-KEM track, and use FrodoKEM or Classic McEliece where conservative long-term confidentiality trade-offs justify the size and performance costs
- Establish comprehensive testing including side-channel evaluation before production deployment
- Design systems with cryptographic agility to enable rapid algorithm updates
- Track HQC as a likely future BSI candidate, but do not treat it as part of today's recommended baseline
- Budget for larger handshake messages and higher computation, especially when using FrodoKEM or Classic McEliece; ML-KEM overhead is usually more manageable, while exact costs depend on protocol design, certificate chains, caching, and hardware
- Train development teams on quantum-safe implementation practices and common pitfalls
BSI Compliance Checklist
Organizations implementing post-quantum key establishment should assess alignment with BSI TR-02102-1 recommendations. This checklist synthesizes BSI recommendations from the technical guideline with practical implementation considerations discovered through our research.
| Requirement | BSI Reference | Implementation Guidance | Priority |
|---|---|---|---|
| Hybrid Implementation | TR-02102-1 §2.1-2.2 | Combine a classical mechanism with a BSI-recommended post-quantum KEM during the transition period; do not plan for classical-only key agreement beyond 2031 | Critical |
| Key Combination / KDF | TR-02102-1 §2.2, §B.1.1 | Use CatKDF with HKDF or KMAC, or KeyCombine per NIST SP 800-227, with context-bound inputs | Critical |
| Algorithm Selection | TR-02102-1 §2.4 | Use only BSI-recommended algorithms and parameters | Critical |
| Migration Timeline | TR-02102-1 §2.1-2.3 | Finish very high protection transitions by 2030-12-31 and phase out classical-only key agreement by 2031-12-31 | Critical |
| Security Level | TR-02102-1 §1.1 | BSI baseline: at least 120-bit security for listed mechanisms; engineering preference: use a comfortable margin where performance and interoperability allow | Critical |
| Randomness Quality | TR-02102-1 §8 | Use random number generators appropriate to the deployment context and aligned with BSI AIS 20/31 guidance; ensure sufficient entropy for key generation, encapsulation, sampling, and ephemeral secrets. | High |
| Side-Channel Protection | TR-02102-1 §1.4 | Use constant-time and side-channel-resistant implementations where secret-dependent timing, memory access, power, electromagnetic, or fault leakage is relevant | High |
| Crypto-Agility | TR-02102-1 §1.2 | Support algorithm updates without breaking changes | High |
| Testing & Validation | N/A | Comprehensive test vectors and KAT compliance | High |
Related Note on Quantum-Safe Signatures
Although this article focuses on key establishment, BSI TR-02102-1 Version 2026-01 also addresses quantum-safe signatures. BSI recommends hybrid quantum-safe signatures in combination with classical signatures, constructed so that the hybrid signature remains secure if at least one component remains secure. For new systems, the relevant quantum-safe signature families include ML-DSA and SLH-DSA parameter sets in NIST Security Strength Categories 3 and 5, while stateful hash-based signatures remain suitable only for scenarios with reliable state management. BSI follows the European transition roadmap and recommends migration to quantum-safe signatures by the end of 2035.
Illustrative Deployment Cost Considerations
Implementing BSI-aligned post-quantum cryptography can require significant engineering and operational investment. The following breakdown is an illustrative scenario model for a hypothetical €1M cryptographic modernization project, not a BSI estimate and not a universal deployment benchmark.
Implementation Cost Breakdown (€1M System)
Actual migration costs depend on system inventory, protocol stack, public-key infrastructure changes, hardware replacement cycles, certification requirements, embedded-device constraints, and operational testing scope. Public reports about the Bundeswehr wide-area network indicate a major quantum-resistant encryption rollout, but public information is not detailed enough to infer a general cost model for commercial deployments.
Future Developments and Recommendations
BSI continues to evaluate additional post-quantum algorithms as the field evolves rapidly. Public information from DLR describes QUANTITY as a cooperation with BSI focused on quantum cryptanalysis and the development and dissemination of secure encryption methods in the age of powerful quantum computers. Version 2026-01 also explicitly points to HQC as a likely future addition after publication and review of the final standard. Organizations must therefore prepare for potential algorithm changes as cryptanalytic techniques advance and as the recommended set evolves.
Key recommendations for developers include implementing comprehensive side-channel countermeasures from the design phase, maintaining close alignment with BSI technical guidelines through regular updates, establishing partnerships with security evaluation laboratories for independent assessment, and contributing to open-source implementations to improve ecosystem security. The transition to post-quantum cryptography represents a fundamental shift requiring sustained investment and expertise development.
How to Cite This Article
APA: PostQuantumSecurity.org. (2025, June 1). BSI-Compliant Post-Quantum Key Establishment: Implementation Pitfalls. https://www.postquantumsecurity.org/publications/bsi-compliant-pqc.html
IEEE: PostQuantumSecurity.org, “BSI-Compliant Post-Quantum Key Establishment: Implementation Pitfalls,” Jun. 1, 2025. [Online]. Available: https://www.postquantumsecurity.org/publications/bsi-compliant-pqc.html
LaTeX/BibTeX:
@misc{pqcryptography_bsi_compliant_pqc,
author = {{PostQuantumSecurity.org}},
title = {BSI-Compliant Post-Quantum Key Establishment: Implementation Pitfalls},
year = {2025},
month = jun,
day = {1},
url = {https://www.postquantumsecurity.org/publications/bsi-compliant-pqc.html}
}
References
- Federal Office for Information Security (BSI). (2026, January 23). BSI TR-02102-1: Cryptographic Mechanisms: Recommendations and Key Lengths, Version 2026-01. BSI-TR-02102-1_2026-01.pdf
- Federal Office for Information Security (BSI). (2025, January 31). BSI TR-02102-1: Cryptographic Mechanisms: Recommendations and Key Lengths, Version 2025-01. Archival comparison copy used for this update: BSI-TR-02102-1_2025-01.pdf
- National Institute of Standards and Technology (NIST). (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
- National Institute of Standards and Technology (NIST). (2025). SP 800-227 Initial Public Draft: Recommendations for Key-Encapsulation Mechanisms. https://csrc.nist.gov/pubs/sp/800/227/ipd
- Longa, P. (2025). FrodoKEM: Learning With Errors Key Encapsulation. IETF CFRG Internet-Draft. https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem/
- DGAP. (2024). How Germany Can Improve Its Standing in Post-Quantum Cryptography. https://dgap.org/en/research/publications/how-germany-can-improve-its-standing-post-quantum-cryptography
- ESUT. (2024). The Bundeswehr's wide area network is now encrypted in a quantum-resistant manner. https://esut.de/en/2024/01/meldungen/47046/weitverkehrsnetz-der-bundeswehr-jetzt-quantenresistent-verschluesselt/
- DLR Quantum Computing Initiative. (2025). DLR × BSI: Working together for more security. https://qci.dlr.de/en/dlr-x-bsi-working-together-for-more-security/