CASE STUDY
KyberLib — production-grade ML-KEM in Rust
Problem
Banks face a November 14, 2026 SWIFT structured-address cutover and a longer NIST post-quantum migration window. Existing PQC implementations ship as policy papers, lab code, or proprietary HSM black boxes — none of which a payments architect can read, test, or sign.
What I built
KyberLib turns FIPS 203 ML-KEM (CRYSTALS-Kyber) into inspectable Rust. Hybrid classical-plus-quantum handshakes, no_std compilation for HSM embedding, crypto-agile abstraction boundaries, and the DORA Article 5 governance evidence boards now need to support PQC migration without taking on opaque vendor risk.
| Signal | Evidence |
|---|---|
| Cryptographic standard | FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber) |
| Hybrid handshake support | Classical TLS + ML-KEM-768 X25519MLKEM768 mode |
| Compilation | no_std — embeds in HSMs, secure enclaves, embedded targets |
| Crypto-agility | Abstraction boundaries enable algorithm swap without API change |
| License | Apache-2.0 / MIT |
External validation
- Cited in EPAA Quantum-Safe Payments white paper (September 2025)
- Featured in the 2026-06-12 article: KyberLib and the Post-Quantum Banking Migration
- Aligned to NIST FIPS 203 / 204 / 205 publication track
Standards
- FIPS 203 (ML-KEM)
- NIST SP 1800-38
- DORA Article 5