[ { "slug": "ml-kem", "name": "ML-KEM", "aka": "CRYSTALS-Kyber", "kind": "Key-encapsulation mechanism (KEM)", "family": "Lattice (Module-LWE)", "standard": "FIPS 203", "standard_url": "https://csrc.nist.gov/pubs/fips/203/final", "body": "NIST (U.S. National Institute of Standards and Technology)", "date": "2024-08-13", "status": "Final", "summary": "ML-KEM is the NIST-standardized post-quantum key-encapsulation mechanism, published as FIPS 203 on 2024-08-13. It is derived from CRYSTALS-Kyber and is the primary algorithm for quantum-resistant key establishment.", "parameter_sets": [ { "name": "ML-KEM-512", "category": 1, "pk": 800, "sk": 1632, "ct_or_sig": 768 }, { "name": "ML-KEM-768", "category": 3, "pk": 1184, "sk": 2400, "ct_or_sig": 1088 }, { "name": "ML-KEM-1024", "category": 5, "pk": 1568, "sk": 3168, "ct_or_sig": 1568 } ], "size_label": "Ciphertext", "deployments": [ "TLS 1.3 hybrid key exchange X25519MLKEM768 (RFC 10024), enabled by default in Chrome, Firefox, Cloudflare, and OpenSSL 3.5+", "OpenSSH: mlkem768x25519-sha256 is the default key exchange since OpenSSH 10.0 (2025-04)", "Signal PQXDH (2023) and the post-quantum Triple Ratchet (2025)", "Apple iMessage PQ3 (2024)", "X.509 certificates: RFC 9935 (2026-03)" ], "audit_focus": [ "Timing leaks in compression and division (the KyberSlash class of bugs found in 2023-2024 across many Kyber implementations)", "Correct implicit rejection in decapsulation (a rejected ciphertext must return a pseudorandom key, never an error signal)", "Input validation required by FIPS 203: modulus check on encapsulation keys, hash check on decapsulation keys, ciphertext length checks", "Constant-time NTT, sampling, and polynomial arithmetic; no secret-dependent branches or memory access", "Randomness: fresh 32-byte seeds per encapsulation, no reuse of d/z across key generations", "Hybrid combiners: shared-secret concatenation order and KDF binding to both ciphertexts, per RFC 10024 and SP 800-227", "Known-answer tests against the FIPS 203 final vectors (not the Round 3 Kyber vectors, which differ)" ], "references": [ [ "FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard", "https://csrc.nist.gov/pubs/fips/203/final" ], [ "NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms (2025-09)", "https://csrc.nist.gov/pubs/sp/800/227/final" ], [ "RFC 10024, Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3 (2026-08)", "https://datatracker.ietf.org/doc/rfc10024/" ], [ "RFC 9935, ML-KEM in X.509 (2026-03)", "https://datatracker.ietf.org/doc/rfc9935/" ], [ "KyberSlash timing vulnerabilities", "https://kyberslash.cr.yp.to/" ] ], "page": "https://pqaudit.org/algorithms/ml-kem/" }, { "slug": "ml-dsa", "name": "ML-DSA", "aka": "CRYSTALS-Dilithium", "kind": "Digital signature", "family": "Lattice (Module-LWE / Module-SIS)", "standard": "FIPS 204", "standard_url": "https://csrc.nist.gov/pubs/fips/204/final", "body": "NIST", "date": "2024-08-13", "status": "Final", "summary": "ML-DSA is the NIST-standardized post-quantum digital signature algorithm, published as FIPS 204 on 2024-08-13. It is derived from CRYSTALS-Dilithium and is NIST's primary recommendation for quantum-resistant signatures.", "parameter_sets": [ { "name": "ML-DSA-44", "category": 2, "pk": 1312, "sk": 2560, "ct_or_sig": 2420 }, { "name": "ML-DSA-65", "category": 3, "pk": 1952, "sk": 4032, "ct_or_sig": 3309 }, { "name": "ML-DSA-87", "category": 5, "pk": 2592, "sk": 4896, "ct_or_sig": 4627 } ], "size_label": "Signature", "deployments": [ "X.509 certificates and CRLs: RFC 9881 (2025-10)", "CNSA 2.0 mandates ML-DSA-87 for U.S. National Security Systems", "OpenSSL 3.5 (2025-04) ships ML-DSA; pyca/cryptography added ML-DSA in 2026", "Composite ML-DSA + ECDSA/RSA signatures for X.509 (IETF LAMPS, in progress)" ], "audit_focus": [ "Rejection-sampling loop must not leak the secret through timing or the number of iterations in a way that correlates with secret data", "Hedged (randomized) vs deterministic signing: deterministic mode is more exposed to fault attacks; FIPS 204 defaults to hedged", "Correct handling of the context string and the pure vs pre-hash (HashML-DSA) variants; domain separation bytes must match FIPS 204", "External-mu signing interfaces (signing a pre-computed message representative) must not allow cross-protocol confusion", "Hint computation, bounds checks on z and h, and the verifier's rejection of malformed signatures", "Constant-time NTT, decomposition, and unpacking; no secret-dependent table lookups", "Known-answer tests against the FIPS 204 final vectors, which differ from Round 3 Dilithium" ], "references": [ [ "FIPS 204, Module-Lattice-Based Digital Signature Standard", "https://csrc.nist.gov/pubs/fips/204/final" ], [ "RFC 9881, ML-DSA in X.509 certificates (2025-10)", "https://datatracker.ietf.org/doc/rfc9881/" ], [ "CNSA 2.0 algorithm list (NSA, updated 2025-05)", "https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF" ] ], "page": "https://pqaudit.org/algorithms/ml-dsa/" }, { "slug": "slh-dsa", "name": "SLH-DSA", "aka": "SPHINCS+", "kind": "Digital signature", "family": "Hash-based (stateless)", "standard": "FIPS 205", "standard_url": "https://csrc.nist.gov/pubs/fips/205/final", "body": "NIST", "date": "2024-08-13", "status": "Final", "summary": "SLH-DSA is the NIST-standardized stateless hash-based signature scheme, published as FIPS 205 on 2024-08-13. It is derived from SPHINCS+ and relies only on the security of hash functions, making it the conservative backup to lattice signatures.", "parameter_sets": [ { "name": "SLH-DSA-SHA2/SHAKE-128s", "category": 1, "pk": 32, "sk": 64, "ct_or_sig": 7856 }, { "name": "SLH-DSA-SHA2/SHAKE-128f", "category": 1, "pk": 32, "sk": 64, "ct_or_sig": 17088 }, { "name": "SLH-DSA-SHA2/SHAKE-192s", "category": 3, "pk": 48, "sk": 96, "ct_or_sig": 16224 }, { "name": "SLH-DSA-SHA2/SHAKE-192f", "category": 3, "pk": 48, "sk": 96, "ct_or_sig": 35664 }, { "name": "SLH-DSA-SHA2/SHAKE-256s", "category": 5, "pk": 64, "sk": 128, "ct_or_sig": 29792 }, { "name": "SLH-DSA-SHA2/SHAKE-256f", "category": 5, "pk": 64, "sk": 128, "ct_or_sig": 49856 } ], "size_label": "Signature", "deployments": [ "X.509 certificates: RFC 9909 (2025-12)", "Firmware and code signing where long-lived trust and minimal assumptions matter", "OpenSSL 3.5 (2025-04) ships SLH-DSA" ], "audit_focus": [ "Fault-injection resistance: a single fault during WOTS+ or FORS signing can leak enough to forge; check for redundant computation or verification-after-signing", "Correct ADRS (address) construction and domain separation across the hypertree, FORS, and WOTS+ layers", "Pre-hash (HashSLH-DSA) and context-string handling must match FIPS 205", "Randomizer generation (opt_rand) and hedged signing", "Denial-of-service surface: signature verification cost and signature size (up to 49,856 bytes) in protocols", "Known-answer tests against FIPS 205 final vectors" ], "references": [ [ "FIPS 205, Stateless Hash-Based Digital Signature Standard", "https://csrc.nist.gov/pubs/fips/205/final" ], [ "RFC 9909, SLH-DSA in X.509 (2025-12)", "https://datatracker.ietf.org/doc/rfc9909/" ] ], "page": "https://pqaudit.org/algorithms/slh-dsa/" }, { "slug": "fn-dsa", "name": "FN-DSA", "aka": "Falcon", "kind": "Digital signature", "family": "Lattice (NTRU, fast-Fourier sampling)", "standard": "FIPS 206 (draft)", "standard_url": "https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization", "body": "NIST", "date": "TBD (draft under review; final expected late 2026 or 2027)", "status": "Draft", "summary": "FN-DSA is NIST's name for Falcon, the fourth post-quantum signature scheme selected in 2022. It will be published as FIPS 206. As of 2026-09 the standard is still in draft; NIST submitted the initial public draft for approval in 2025-08 and a final standard is expected in late 2026 or 2027.", "parameter_sets": [ { "name": "FN-DSA-512 (Falcon-512)", "category": 1, "pk": 897, "sk": 1281, "ct_or_sig": 666 }, { "name": "FN-DSA-1024 (Falcon-1024)", "category": 5, "pk": 1793, "sk": 2305, "ct_or_sig": 1280 } ], "size_label": "Signature (approx., variable-length encoding)", "deployments": [ "Blockchains and constrained protocols that need the smallest post-quantum signatures (about 666 bytes at category 1)", "Not yet approved for FIPS 140-3 validation until FIPS 206 is final" ], "audit_focus": [ "The floating-point Gaussian sampler is the hardest part of any post-quantum standard to implement in constant time; audit emulated-FP paths and every platform-specific FPU behavior", "Key generation (NTRU solve) correctness and secret-dependent timing", "Signature encoding and the variable-length compression format", "Reference implementations still change between draft versions; verify against the exact draft the project targets" ], "references": [ [ "NIST PQC standardization project page", "https://csrc.nist.gov/projects/post-quantum-cryptography" ], [ "FIPS 206 status update (NIST, 2025)", "https://csrc.nist.gov/presentations/2025/fips-206-fn-dsa-falcon" ], [ "Falcon specification", "https://falcon-sign.info/" ] ], "page": "https://pqaudit.org/algorithms/fn-dsa/" }, { "slug": "hqc", "name": "HQC", "aka": "Hamming Quasi-Cyclic", "kind": "Key-encapsulation mechanism (KEM)", "family": "Code-based (quasi-cyclic codes)", "standard": "FIPS 207 (expected designation, draft pending)", "standard_url": "https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption", "body": "NIST", "date": "Selected 2025-03-11; draft standard expected 2026, final 2027", "status": "Selected, draft pending", "summary": "HQC is the code-based KEM that NIST selected on 2025-03-11 (NIST IR 8545) as a backup to ML-KEM, so that a break of lattice cryptography does not leave the world without a standardized post-quantum KEM. NIST expects to publish a draft standard, anticipated as FIPS 207, in 2026 and a final standard in 2027.", "parameter_sets": [ { "name": "HQC-128", "category": 1, "pk": 2249, "sk": 2305, "ct_or_sig": 4433 }, { "name": "HQC-192", "category": 3, "pk": 4522, "sk": 4586, "ct_or_sig": 8978 }, { "name": "HQC-256", "category": 5, "pk": 7245, "sk": 7317, "ct_or_sig": 14421 } ], "size_label": "Ciphertext (Round 4 submission sizes)", "deployments": [ "No production deployments expected before the draft standard; available in liboqs and reference code" ], "audit_focus": [ "Constant-time decoding of the concatenated Reed-Muller / Reed-Solomon code", "Decryption-failure rate and its impact on IND-CCA security", "Quarkslab's 2025 work found correctness and security bugs in several HQC implementations; test against the latest specification", "Parameter and encoding changes between Round 4 and the draft standard" ], "references": [ [ "NIST selects HQC as fifth algorithm (2025-03-11)", "https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption" ], [ "NIST IR 8545, Status report on the fourth round", "https://csrc.nist.gov/pubs/ir/8545/final" ], [ "Quarkslab: Finding bugs in implementations of HQC", "https://blog.quarkslab.com/finding-bugs-in-implementations-of-hqc-the-fifth-post-quantum-standard.html" ] ], "page": "https://pqaudit.org/algorithms/hqc/" }, { "slug": "lms-hss", "name": "LMS / HSS", "aka": "Leighton-Micali Signatures, Hierarchical Signature System", "kind": "Digital signature (stateful)", "family": "Hash-based (stateful)", "standard": "RFC 8554 and NIST SP 800-208", "standard_url": "https://csrc.nist.gov/pubs/sp/800/208/final", "body": "IETF / IRTF CFRG (RFC 8554) and NIST (SP 800-208)", "date": "RFC 8554: 2019-04; SP 800-208: 2020-10-30", "status": "Final", "summary": "LMS and its multi-tree variant HSS are stateful hash-based signatures specified in RFC 8554 (2019-04) and approved by NIST in SP 800-208 (2020-10). They are the signature schemes CNSA 2.0 requires for firmware and software signing, and are the first post-quantum signatures many hardware roots of trust support.", "parameter_sets": [ { "name": "LMS_SHA256_M32_H10 (typical)", "category": 5, "pk": 60, "sk": "varies", "ct_or_sig": 1456 }, { "name": "HSS with 2 levels of H10 (typical)", "category": 5, "pk": 60, "sk": "varies", "ct_or_sig": 2964 } ], "size_label": "Signature", "deployments": [ "CNSA 2.0 firmware and software signing (exclusive use required by 2030)", "Hardware roots of trust, secure boot, HSM-backed code signing" ], "audit_focus": [ "State management is the whole game: a one-time key reused once allows forgery. Audit state persistence, atomic updates, backups, HSM cloning, and crash recovery", "SP 800-208 restricts key generation and signing to hardware cryptographic modules for FIPS validation", "Parameter-set validation on the verifier, including the Winternitz parameter and tree height", "Domain separation constants and the exact hash-input layouts of RFC 8554" ], "references": [ [ "RFC 8554, Leighton-Micali Hash-Based Signatures", "https://datatracker.ietf.org/doc/rfc8554/" ], [ "NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes", "https://csrc.nist.gov/pubs/sp/800/208/final" ] ], "page": "https://pqaudit.org/algorithms/lms-hss/" }, { "slug": "xmss", "name": "XMSS / XMSS^MT", "aka": "eXtended Merkle Signature Scheme", "kind": "Digital signature (stateful)", "family": "Hash-based (stateful)", "standard": "RFC 8391 and NIST SP 800-208", "standard_url": "https://datatracker.ietf.org/doc/rfc8391/", "body": "IRTF CFRG (RFC 8391) and NIST (SP 800-208)", "date": "RFC 8391: 2018-05; SP 800-208: 2020-10-30", "status": "Final", "summary": "XMSS and its multi-tree variant XMSS^MT are stateful hash-based signatures specified in RFC 8391 (2018-05) and approved by NIST in SP 800-208 (2020-10). Like LMS, they are permitted under CNSA 2.0 and are used for firmware signing and in some blockchains (for example QRL).", "parameter_sets": [ { "name": "XMSS-SHA2_10_256", "category": 5, "pk": 64, "sk": "varies", "ct_or_sig": 2500 }, { "name": "XMSS-SHA2_20_256", "category": 5, "pk": 64, "sk": "varies", "ct_or_sig": 2820 } ], "size_label": "Signature", "deployments": [ "CNSA 2.0 firmware and software signing", "Quantum Resistant Ledger (QRL) blockchain" ], "audit_focus": [ "Same stateful-key risks as LMS: index reuse, state rollback, backup/restore, and multi-instance deployments", "Correct WOTS+ chaining and L-tree computation; hash-address (ADRS) construction", "Verifier-side parameter validation and bounds on index values" ], "references": [ [ "RFC 8391, XMSS: eXtended Merkle Signature Scheme", "https://datatracker.ietf.org/doc/rfc8391/" ], [ "NIST SP 800-208", "https://csrc.nist.gov/pubs/sp/800/208/final" ] ], "page": "https://pqaudit.org/algorithms/xmss/" }, { "slug": "hybrid-tls-x25519mlkem768", "name": "Hybrid TLS 1.3 key exchange (X25519MLKEM768)", "aka": "ECDHE-MLKEM", "kind": "Protocol integration (hybrid KEM)", "family": "Hybrid: X25519 or NIST P-curves combined with ML-KEM", "standard": "RFC 10024", "standard_url": "https://datatracker.ietf.org/doc/rfc10024/", "body": "IETF TLS Working Group", "date": "2026-08", "status": "Final (Proposed Standard)", "summary": "RFC 10024 (2026-08) standardizes hybrid post-quantum key agreement for TLS 1.3, defining the named groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. X25519MLKEM768 is the default post-quantum key exchange in Chrome, Firefox, Safari, Cloudflare, OpenSSL 3.5+, and Go, and is the most widely deployed post-quantum cryptography on the internet.", "parameter_sets": [ { "name": "X25519MLKEM768", "category": 3, "pk": 1216, "sk": "n/a", "ct_or_sig": 1120 }, { "name": "SecP256r1MLKEM768", "category": 3, "pk": 1249, "sk": "n/a", "ct_or_sig": 1153 }, { "name": "SecP384r1MLKEM1024", "category": 5, "pk": 1665, "sk": "n/a", "ct_or_sig": 1665 } ], "size_label": "Server key share", "deployments": [ "Enabled by default in Chrome 131+, Firefox 132+, Safari 26+, Go 1.24+, OpenSSL 3.5+, BoringSSL, and Cloudflare's edge", "Roughly half of all TLS connections at large CDNs already negotiate a hybrid post-quantum key exchange" ], "audit_focus": [ "Key-share encoding order: X25519MLKEM768 places the ML-KEM encapsulation key before the X25519 key, the reverse of the P-curve variants. Getting this wrong is a common interop and security bug", "Shared-secret concatenation order into the TLS key schedule and that both components are bound", "Downgrade behavior when the peer does not support hybrid groups; HelloRetryRequest handling", "ML-KEM encapsulation-key validation on the server side (modulus check) and ciphertext length checks", "Middlebox and MTU issues from the 1,216-byte client key share (ClientHello now spans multiple TCP segments)" ], "references": [ [ "RFC 10024, Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3", "https://datatracker.ietf.org/doc/rfc10024/" ], [ "IETF TLS working group draft history", "https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/" ] ], "page": "https://pqaudit.org/algorithms/hybrid-tls-x25519mlkem768/" }, { "slug": "classic-mceliece", "name": "Classic McEliece", "aka": "McEliece (Goppa codes)", "kind": "Key-encapsulation mechanism (KEM)", "family": "Code-based (binary Goppa codes)", "standard": "ISO/IEC standardization in progress; not selected by NIST", "standard_url": "https://classic.mceliece.org/", "body": "ISO/IEC JTC 1/SC 27 (in progress); recommended by BSI (Germany) TR-02102-1", "date": "NIST fourth round concluded 2025-03-11 without selecting it", "status": "Not a NIST standard; ISO/IEC process ongoing", "summary": "Classic McEliece is the oldest post-quantum KEM design (1978) and the most conservative. NIST did not select it in the fourth round (2025-03-11) because of its very large public keys, but Germany's BSI recommends it in TR-02102-1 and it is being standardized through ISO/IEC. It matters for audits because European and defense customers deploy it.", "parameter_sets": [ { "name": "mceliece348864", "category": 1, "pk": 261120, "sk": 6492, "ct_or_sig": 96 }, { "name": "mceliece460896", "category": 3, "pk": 524160, "sk": 13608, "ct_or_sig": 156 }, { "name": "mceliece6688128", "category": 5, "pk": 1044992, "sk": 13932, "ct_or_sig": 208 } ], "size_label": "Ciphertext", "deployments": [ "Mullvad VPN and some WireGuard-based products", "German and EU government contexts under BSI TR-02102-1" ], "audit_focus": [ "Constant-time Goppa decoding (Berlekamp-Massey) and the Benes network for secret permutation", "Handling of the ~1 MB public key: memory safety, transport, caching", "Key generation failure handling and rejection sampling" ], "references": [ [ "Classic McEliece project", "https://classic.mceliece.org/" ], [ "BSI TR-02102-1 Cryptographic Mechanisms", "https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr02102_node.html" ] ], "page": "https://pqaudit.org/algorithms/classic-mceliece/" }, { "slug": "frodokem", "name": "FrodoKEM", "aka": "Frodo", "kind": "Key-encapsulation mechanism (KEM)", "family": "Lattice (plain LWE, unstructured)", "standard": "ISO/IEC 18033-2 amendment in progress; not selected by NIST", "standard_url": "https://frodokem.org/", "body": "ISO/IEC JTC 1/SC 27 (in progress); recommended by BSI (Germany) and ANSSI (France)", "date": "Dropped from NIST process after Round 3 (2022-07); ISO/IEC work ongoing", "status": "Not a NIST standard; ISO/IEC process ongoing", "summary": "FrodoKEM is a conservative lattice KEM based on unstructured LWE, avoiding the algebraic structure of ML-KEM. NIST did not advance it past Round 3 for performance reasons, but BSI and ANSSI recommend it and it is being standardized under ISO/IEC 18033-2. It is relevant for European regulated deployments.", "parameter_sets": [ { "name": "FrodoKEM-640", "category": 1, "pk": 9616, "sk": 19888, "ct_or_sig": 9720 }, { "name": "FrodoKEM-976", "category": 3, "pk": 15632, "sk": 31296, "ct_or_sig": 15744 }, { "name": "FrodoKEM-1344", "category": 5, "pk": 21520, "sk": 43088, "ct_or_sig": 21632 } ], "size_label": "Ciphertext", "deployments": [ "European government and regulated deployments; available in liboqs" ], "audit_focus": [ "Matrix generation from seed (AES vs SHAKE variants) and its performance/side-channel profile", "Constant-time sampling from the rounded-Gaussian table", "Ephemeral-only (eFrodoKEM) vs static-key variants and the implicit rejection differences between them" ], "references": [ [ "FrodoKEM project", "https://frodokem.org/" ] ], "page": "https://pqaudit.org/algorithms/frodokem/" } ]