Chapter 25 — Hybrid mode, crypto-agility, and how to migrate

Why hybrid, not replace

The PQC algorithms are new. Lattice cryptanalysis is an active field. A catastrophic classical break of ML-KEM in 2027 is unlikely but not impossible — and it would be far worse to have bet everything on it.

   HYBRID KEY EXCHANGE

     shared_secret = KDF( X25519_secret  ||  ML-KEM-768_secret )

   To break this, an attacker must break BOTH:
     * X25519  -- needs a quantum computer
     * ML-KEM  -- needs a classical break of Module-LWE

   Safe as long as EITHER remains unbroken. You only lose if both fall.

This is why the real-world rollout is named X25519MLKEM768, not MLKEM768 alone. Chrome, Firefox, Cloudflare, AWS, and Google have had hybrid key exchange on by default for most TLS 1.3 connections since 2024–2025. If you use a modern browser, you're already doing post-quantum key exchange on many sites.

   Check your own browser: visit  pq.cloudflareresearch.com
   or run:  openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768
            then look for  "Negotiated TLS1.3 group: X25519MLKEM768"

For signatures, hybrid is messier (two signatures = two failure modes to validate, bigger chains) and the HNDL urgency isn't there, so most deployments are waiting or doing classical-now / PQC-ready.

Crypto-agility — the real lesson

The deeper takeaway from this whole Part: the specific algorithm will change again. Systems that hard-coded "RSA-2048" or "SHA-1" needed painful surgery. Design so the next transition is easy.

   CRYPTO-AGILITY CHECKLIST

   [ ] Algorithms named in CONFIG, not compiled into logic.
   [ ] Every stored ciphertext / hash / signature carries an ALGORITHM ID
       and VERSION prefix, so you can tell old from new and migrate lazily.
         e.g.  v2:mlkem768:<data>     $argon2id$v=19$...   (Ch 10 does this)
   [ ] Key storage abstracted behind an interface (KMS/HSM), so key type
       is swappable.
   [ ] You can run TWO algorithms in parallel during a migration window
       (decrypt-with-either, verify-either, write-with-new).
   [ ] A documented, current CRYPTO INVENTORY: every algorithm, key size,
       key location, expiry, and owner. (You can't migrate what you can't see.)
   [ ] Certificate/key rotation is already automated and routine -- if
       rotating a key is scary, migration will be a disaster.
   [ ] Third-party dependencies audited for buried crypto (that old JWT
       library, the device SDK, the payment gateway).

The migration playbook

   PHASE 0  INVENTORY (do this now, regardless of timeline)
            - enumerate every use of asymmetric crypto: TLS, SSH, VPN, JWT,
              code signing, DB/disk encryption key wrapping, backups, mTLS,
              document signing, firmware.
            - for each: algorithm, key size, key location, data lifetime,
              is it HNDL-sensitive?

   PHASE 1  PRIORITISE by (data-secrecy-lifetime) x (exposure)
            - long-lived confidential data over untrusted networks first
            - then authentication/signing
            - symmetric: just confirm AES-256 / SHA-384+ everywhere

   PHASE 2  UPGRADE THE PLUMBING
            - get to TLS 1.3, modern libraries (OpenSSL 3.5+, BoringSSL,
              Go 1.24+, rustls) that support ML-KEM
            - achieve crypto-agility (checklist above) -- this is most of
              the work and it's valuable even if PQC never mattered

   PHASE 3  ENABLE HYBRID KEY EXCHANGE
            - X25519MLKEM768 on TLS endpoints (often one config line or a
              library upgrade)
            - measure: handshake size, latency, CPU, and
              middlebox/"protocol ossification" breakage on old kit

   PHASE 4  PQC SIGNATURES / CERTIFICATES
            - as CAs and standards mature; test ML-DSA cert chains
            - firmware/boot signing -> SLH-DSA or stateful hash-based now
              (long device lifetimes, can't easily update the verifier)

   PHASE 5  DEPRECATE classical-only paths per the NIST/NCSC dates.

   shop.securesh.op  (customer TLS)
     -> Phase 3 now: enable X25519MLKEM768. Card data + PII crossing the
        internet is HNDL-sensitive (PCI + GDPR, 7-year retention).

   orders-api <-> database  (internal mTLS)
     -> internal network, shorter data-at-rest exposure, but backups live
        for years -> Phase 3 soon; ensure backup encryption uses AES-256
        with keys wrapped by a KMS you can re-wrap.

   deploy signing  (the Ch 22 release tool)
     -> Phase 4: plan ML-DSA-65 signatures; keep Ed25519 in hybrid until
        the toolchain is proven. Not HNDL-urgent.

   admin SSO / JWT (RS256)
     -> tokens live minutes; low HNDL risk. Migrate with the library
        upgrade cycle, not as an emergency.

   secure boot on the warehouse scanners (IoT)
     -> Phase 4 priority despite low data sensitivity: 10-year field life,
        no practical way to update the bootloader's trust anchor later
        -> SLH-DSA now.

   1. Pick a system you know (a repo, a service, your home lab).
   2. Grep for crypto: `rsa`, `ec`, `ed25519`, `x25519`, `aes`, `sha`,
      `jwt`, `tls`, `ssl`, `certificate`, `PRIVATE KEY`, `KMS`, `bcrypt`.
      Check: TLS config, SSH config, CI secrets, IaC, container base images,
      language crypto calls, dependency lockfiles.
   3. Build a table: component | algorithm | key size | key location |
      data lifetime | HNDL-sensitive? | migration phase | owner.
   4. Identify the top 3 items to migrate first and justify the ordering
      using (secrecy-lifetime x exposure x difficulty-to-change-later).
   5. For one TLS endpoint, actually test hybrid:
        openssl s_client -connect <host>:443 -groups X25519MLKEM768 -brief
      (needs OpenSSL 3.5+). Record whether it negotiated.