Demystifying Post-Quantum Cryptography: The Hybrid Approach#

Rutvik Kshirsagar, Shreyas Mahangade, Clemens Lang (Red Hat)

• Why: PQC migration is shifting from "someday" to procurement requirements, and hybrid classical+PQC is the only deployment path that doesn't break interoperability. This is the practical migration talk with a live TLS demo.
• What: The hybrid transition using NIST's standardized algorithms — ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures — where hybrid applies only to the key exchange (X25519MLKEM768), keeping TLS 1.3's cipher-suite agility intact, plus PQC signatures for software supply chain (hybrid EdDSA/ML-DSA OpenPGP signing of RPMs via Sequoia).
• How: Deployment math: time-to-transition (standards → vendor support → upgrades → decommissioning) must be shorter than the time data must remain secret — hence harvest-now-decrypt-later concern. Momentum numbers: ~60% of Cloudflare's human TLS traffic already negotiates hybrid ML-KEM, Chrome 116+ by default, OpenSSL 3.5+ native support, Fedora 43, IBM z16 firmware.
• Where applicable: Any TLS-terminating service, PKI, or signing pipeline with long-lived artifacts (firmware, root certs, package signing). The guidance on ML-KEM/ML-DSA variant selection (fast handshakes vs. long-term margins) is directly usable.