Q-Day threat model — what 'cryptographically relevant quantum' actually breaks, and when

1. The exact problem this technology solves (real attack model)

Q-Day is shorthand for the moment a cryptographically-relevant quantum computer (CRQC) — meaning one with enough logical qubits, sufficient gate fidelity and a deep enough coherence budget to run Shor's algorithm against 2048-bit integers or 256-bit elliptic-curve groups — becomes operational in the hands of an adversary willing to use it. Estimates from the 2023 Global Risk Institute report, the NSA CNSA 2.0 timetable (mandating PQ for NSS by 2035, with new procurement from 2027) and the BSI/ANSSI 2024 joint position paper cluster around the 2030–2035 window for asymmetric break, with a non-trivial tail toward 2040.

The threat is not symmetric. AES-256-GCM and SHA-384 lose roughly half their security margin under Grover, which is a manageable downgrade. The damage is concentrated in the asymmetric primitives Irish regulated firms actually deploy in production:

• RSA-2048 and RSA-3072 in TLS server certs, S/MIME, code-signing CAs, EU Trust List QTSPs.
• ECDSA P-256, Ed25519 in TLS, DNSSEC ZSK/KSK, JWT, OpenSSH host keys, container-image signatures.
• X25519 and ECDH P-256 in TLS 1.3 key exchange, Signal, WireGuard, IKEv2.
• DH groups in legacy IPsec.

The operationally urgent attack is Harvest Now, Decrypt Later (HNDL). An adversary that records ciphertext today — TLS sessions, IKEv2 tunnels, encrypted backups, replicated database WAL streams — and retains the key-exchange transcript can decrypt retrospectively once a CRQC exists. Anything with a confidentiality lifetime exceeding the time-to-CRQC is already compromised in expectation. Patient health records (Article 9 GDPR), Central Bank supervisory data, IP/source code, and sealed legal correspondence sit squarely in that bucket.

Authentication is a different timeline. A signature forged after Q-Day cannot retrospectively forge a TLS handshake from 2026, but it does break trust roots, software-update channels and DNSSEC chains going forward — so root keys with multi-year validity (CA roots issued today expire 2046+) need PQ signatures now even though the attack is future-only.

2. The cryptographic primitive in technical detail

NIST finalised three standards on 13 August 2024:

• FIPS 203 — ML-KEM (CRYSTALS-Kyber). A lattice-based KEM whose security reduces to Module-LWE over the ring R_q = Z_q[X]/(X^256 + 1) with q = 3329. Parameter sets: ML-KEM-512 (Cat 1, ~AES-128), ML-KEM-768 (Cat 3, ~AES-192) and ML-KEM-1024 (Cat 5, ~AES-256). Public keys are 800/1184/1568 bytes, ciphertexts 768/1088/1568 bytes. Security target is IND-CCA2 via a Fujisaki-Okamoto transform applied to the underlying IND-CPA Kyber.PKE. Decapsulation uses implicit rejection — a deterministic pseudo-random shared secret on failure, not an explicit error — which is what defeats the Hofheinz-Hövelmanns-Kiltz class of decryption-failure attacks.
• FIPS 204 — ML-DSA (CRYSTALS-Dilithium). Lattice signatures via Fiat-Shamir-with-aborts over Module-LWE and Module-SIS. Parameter sets ML-DSA-44/65/87. Signatures are 2420/3309/4627 bytes; public keys 1312/1952/2592 bytes. Target is EUF-CMA (and SUF-CMA in the standardised variant). The rejection sampling means signing time is variable — relevant for side-channel hygiene and for SLA budgets on high-QPS signers.
• FIPS 205 — SLH-DSA (SPHINCS+). Stateless hash-based signatures, security relies only on the second-preimage resistance of the underlying hash (SHA2 or SHAKE). Conservative fallback: no number-theoretic or lattice assumption. Cost: signatures are 7856–49856 bytes and signing is two to three orders of magnitude slower than ML-DSA. Use it for root-of-trust, firmware-signing, CA roots — anywhere signature size is amortised over a long validity window.

FALCON (FN-DSA) is still drafting — expect FIPS 206 in 2026. Don't deploy it yet outside tightly controlled pilots; the floating-point Gaussian sampler is a side-channel minefield.

3. Reference implementations available in 2026 and their readiness

• liboqs 0.11+ (Open Quantum Safe). Reference implementations of all three FIPS standards plus hybrids. Production-grade for ML-KEM and ML-DSA; SLH-DSA performance has improved but remains the slow path.
• OpenSSL 3.4 with the oqs-provider, and the upstream openssl-pq integration in 3.5. Use the provider for ML-KEM in TLS 1.3 and X.509 with ML-DSA via OIDs 2.16.840.1.101.3.4.3.17 (ML-DSA-44), .18, .19.
• BoringSSL ships hybrid X25519MLKEM768 (codepoint 0x11EC, per draft-kwiatkowski-tls-ecdhe-mlkem) — this is what Chrome and Cloudflare's edge negotiate today.
• BIND 9.20 has experimental ML-DSA DNSKEY/RRSIG support; production DNSSEC PQ deployment is gated on root-zone signer policy at IANA, which is not moving in 2026.
• OpenSSH 9.9+ defaults KexAlgorithms to sntrup761x25519-sha512,mlkem768x25519-sha256. Host-key PQ signatures are still post-9.x roadmap.
• AWS KMS hybrid post-quantum TLS for the KMS API endpoint (since 2020, now ML-KEM-based); GCP Cloud KMS and Azure Key Vault expose ML-DSA signing keys in preview tiers.
• Cloudflare negotiates X25519MLKEM768 for a majority of inbound TLS 1.3 connections from modern browsers as of 2024.

4. Deployment pattern

The non-negotiable rule for 2026 deployments: hybrid, not pure PQ. Combine a classical KEM with ML-KEM so a cryptanalytic break in either leaves you standing. For TLS 1.3 the IETF codepoint X25519MLKEM768 (0x11EC) is the one to negotiate.

nginx 1.27 fronted by an OpenSSL build with oqs-provider:

# /etc/nginx/conf.d/pq.conf
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:P-256;
ssl_conf_command Groups X25519MLKEM768:X25519;
ssl_certificate /etc/ssl/hybrid/fullchain.pem; # ML-DSA-65 + ECDSA P-256 dual cert
ssl_certificate_key /etc/ssl/hybrid/privkey.pem;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

Issuing the dual-algorithm leaf via an internal CA with the oqs-provider:

openssl req -new -newkey mldsa65 -keyout pq.key -out pq.csr \
    -subj "/CN=api.internal.example.ie" -nodes \
    -provider oqsprovider -provider default

openssl x509 -req -in pq.csr -CA root-mldsa65.pem -CAkey root-mldsa65.key \
    -days 365 -out pq.crt -extfile v3.ext \
    -provider oqsprovider -provider default

5. What goes wrong in production

• MTU and fragmentation. ML-KEM-768 client hello + ML-DSA-65 cert chain pushes the TLS ServerHello + Certificate flight past 9 KB. Middleboxes that assumed handshakes fit in two packets drop or stall connections. Watch for TCP retransmits on the first flight.
• Initial congestion window. With IW=10 and ~9 KB of handshake, you're now blocking on RTT for the second round. First-byte latency regresses by one RTT on cold connections — measurable on trans

  Schedule a sovereign-cryptography assessment

  Book a security call →