NIST published the final version of IR 8547, its plan for retiring quantum-vulnerable public-key cryptography, on October 27.
NIST deprecates RSA and ECDSA signatures at 112 bits or more, EdDSA at 128 bits or more, and DH, MQV and RSA key establishment at 112 bits or more, all after 2030. All of them are disallowed under NIST standards and guidelines after 2035.
P-256, P-384, RSA-3072 and Ed25519 had no deprecation step in the November 2024 draft and are now deprecated on the same day as RSA-2048.
A deprecated algorithm is usable, with a risk the data owner must examine before deciding to continue. A disallowed one is no longer allowed for the stated purpose. Decrypting old ciphertext and verifying old signatures fall under a third status, legacy use. NIST doesn't say how long it will last for these algorithms.
From 2031, anyone following NIST's statuses needs a recorded risk decision for each classical-only key exchange or signature they keep.
For hybrid key establishment, the SP 800-56C composite technique stays allowed even with a disallowed input, and a combination with at least one approved input can be FIPS 140-validated. Under SP 800-56C Rev. 2, a hybrid secret Z || T qualifies for approved key derivation when Z comes from an approved scheme. An ML-KEM secret counts.
The IETF put ML-KEM first in X25519MLKEM768, so the ML-KEM implementation is the component that must be validated. In SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDH secret comes first. In SP 800-227, NIST already approves combiners with the approved secret in any position, but in IR 8547 it ties the either-order rule to a promised SP 800-56C update. Vendors shipping those groups should ask their labs how they'll be treated after 2035.
I'd keep the TLS combiner inside TLS. In SP 800-227 section 4.6.3, NIST says a combiner that uses only the shared secrets doesn't, in general, preserve IND-CCA security when only one component remains secure. The security analysis in RFC 10024 relies on the TLS 1.3 transcript.
The X25519MLKEM768 key share adds about 1.2 KB, so the ClientHello can span two packets, and some servers reject it instead of falling back to classical key exchange. Log the negotiated group for each production connection, and check every hop separately.
Hybrid key exchange protects session keys only, so the RSA or ECDSA chain needs its own migration. An ML-DSA-44 signature is 2,420 bytes, against 64 to 72 for ECDSA on P-256.
NIST gives key establishment and signatures the same dates in Tables 2 and 4. In the same report, it explains that harvest now, decrypt later makes key establishment more urgent.
In Section 3.1.2, NIST still says authentication may stay classical until a CRQC is available and then switch immediately. Under Table 2, the same algorithms are disallowed after 2035 either way.
Dual signatures get a definition but no encoding and no post-2035 status. Contracts and archives that must stay verifiable for decades need evidence records renewed with post-quantum algorithms, but NIST doesn't mention them in IR 8547.
HQC is the alternative KEM, with a FIPS in development. ML-KEM-768 is the default parameter set. LMS and XMSS are named for software and firmware signing.
NIST added Ascon to the symmetric tables and printed its AEAD entry as "AES-AEAD128" by mistake. It also corrected SHAKE256's preimage strength from 512 to 256 bits. The statuses that module validation applies come from SP 800-131A, and its Revision 3 is still a draft.
Full analysis, with a draft-to-final comparison table: https://postquantum.com/security-pqc/nist-ir-8547-final/
I teach the US requirements behind these dates in PQC Compliance: United States at Quantum Academy: https://quantumacademy.com/courses/pqc-compliance-us/
#infosec #cryptography #PQC #postquantum #NIST #TLS #FIPS
IACR Cryptology ePrint ArchiveSHAKEing SLH-DSA with Non-profiled SCAsSLH-DSA is a hash-based digital signature algorithm, standardised by NIST as a post-quantum signature scheme. While prior work has analysed the vulnerability of its pseudorandom function (PRF) to differential side-channel analysis (SCA), no prior work has thoroughly examined this vulnerability under SHAKE as the PRF, nor recovered a full secret seed in practice. In this work, we address this gap b
