PQUIP L. Prabel Internet-Draft S. Sun Intended status: Standards Track G. Zeng Expires: 3 January 2026 G. Wang Huawei 2 July 2025 Post-Quantum Algorithms guidance draft-prabel-pquip-pqc-guidance-00 Abstract This document provides general information (such as parameter sizes, security assumptions, and targeted security models) on a range of widely studied post-quantum cryptographic algorithms, including Key Encapsulation Mechanisms (KEMs) and digital signature schemes. The cryptographic schemes described in this document are among those recommended by major security agencies and/or standardization bodies, and are believed to be secure against Cryptographically Relevant Quantum Computer (CRQC). The goal of this document is to offer a high-level overview of these schemes and their distinguishing features, to help implementers, protocol designers, standards developers, and policymakers in understanding and selecting appropriate post-quantum cryptographic primitives for use in protocols and systems. By aggregating and presenting this information in a unified format, this document aims to facilitate informed decision-making and interoperability during the migration to post-quantum cryptography, and to encourage consistent practices when evaluating and deploying PQC schemes in cryptographic protocols. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-prabel-pquip-pqc- guidance/. Discussion of this document takes place on the Post-Quantum Use In Protocols Working Group mailing list (mailto:pqc@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/pqc/. Subscribe at https://www.ietf.org/mailman/listinfo/pqc/. Prabel, et al. Expires 3 January 2026 [Page 1] Internet-Draft PQC Algo Guidance July 2025 Source for this draft and an issue tracker can be found at https://github.com/USER/REPO. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Parameter Sizes . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Key Encapsulation Mechanism (KEM) Schemes . . . . . . . . 4 3.1.1. ML-KEM . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.2. FrodoKEM . . . . . . . . . . . . . . . . . . . . . . 5 3.1.3. Classic McEliece . . . . . . . . . . . . . . . . . . 6 3.1.4. HQC . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.5. NTRU . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Signature Scheme . . . . . . . . . . . . . . . . . . . . 9 3.2.1. ML-DSA . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. FN-DSA . . . . . . . . . . . . . . . . . . . . . . . 10 Prabel, et al. Expires 3 January 2026 [Page 2] Internet-Draft PQC Algo Guidance July 2025 3.2.3. SLH-DSA . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. LMS . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.5. XMSS / XMSS^MT . . . . . . . . . . . . . . . . . . . 19 4. Security Properties . . . . . . . . . . . . . . . . . . . . . 21 4.1. Quantum-Vulnerable Asymmetric Cryptography . . . . . . . 21 4.2. Quantum-Safe Asymmetric Cryptography . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . 23 6.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document follows the terminology for post-quantum hybrid schemes defined in [I-D.draft-ietf-pquip-pqt-hybrid-terminology-04]. This section recalls some of this terminology, but also adds other definitions used throughout the whole document: _Traditional Asymmetric Cryptographic Algorithm_: An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. They can also be called classical or conventional algorithms. _Post-Quantum Asymmetric Cryptographic Algorithm_: An asymmetric cryptographic algorithm that is intended to be secure against attacks using quantum computers as well as classical computers. They can also be called quantum-resistant or quantum-safe algorithms. As with all cryptography, it always remains the case that attacks, either quantum or classical, may be found against post-quantum algorithms. Therefore it should not be assumed that just because an algorithm is designed to provide post-quantum security it will not be compromised. Should an attack be found against a post-quantum algorithm, it is commonly still referred to as a post- quantum algorithm as they were designed to protect against an adversary with access to a CRQC and the labels are referring to the designed or desired properties. Prabel, et al. Expires 3 January 2026 [Page 3] Internet-Draft PQC Algo Guidance July 2025 _IND-CCA2_: Indistinguishability under Adaptive Chosen-Ciphertext Attack. It is the standard security notion for KEM schemes. _EUF-CMA_: Existential Unforgeability under Chosen-Message Attack. It is the standard security notion for digital signature schemes. _SUF-CMA_: Strong Existential Unforgeability under Chosen-Message Attack. It is a stronger security notion than EUF-CMA. 3. Parameter Sizes This section is divided into two different subsections, one focused on Key Encapsulation Mechanism, and the other on signature schemes. The "claimed security level" in each table refers to the NIST Post- Quantum Cryptography Evaluation Criteria. We summarize this classification in Table 1 below. Additional details is available at [IR.8547]. +===================+===========================+==========+ | Security Category | Attack Type | Example | +===================+===========================+==========+ | 1 | Key search on a block | AES-128 | | | cipher with a 128-bit key | | +-------------------+---------------------------+----------+ | 2 | Collision search on a | SHA-256 | | | 256-bit hash function | | +-------------------+---------------------------+----------+ | 3 | Key search on a block | AES-192 | | | cipher with a 192-bit key | | +-------------------+---------------------------+----------+ | 4 | Collision search on a | SHA3-384 | | | 384-bit hash function | | +-------------------+---------------------------+----------+ | 5 | Key search on a block | AES-256 | | | cipher with a 256-bit key | | +-------------------+---------------------------+----------+ Table 1: NIST Post-Quantum Cryptography Classification 3.1. Key Encapsulation Mechanism (KEM) Schemes 3.1.1. ML-KEM ML-KEM, formerly known as CRYSTALS-Kyber, is a structured lattice- based KEM, the first PQC KEM standardized by NIST. The security of ML-KEM is based on the computational hardness of the Module Learning with Errors problem. Prabel, et al. Expires 3 January 2026 [Page 4] Internet-Draft PQC Algo Guidance July 2025 NIST recommends Security Level 3 by default, and European security agencies recommend a minimum of the same security level. The NIST specification of ML-KEM is available at [MLKEM.SPEC]. +=============+========+=========+============+========+==========+ | Scheme | Public | Private | Ciphertext | Shared | Claimed | | | Key | Key | | Secret | Security | | | | | | | Level | +=============+========+=========+============+========+==========+ | ML-KEM-512 | 800 | 1632 | 768 | 32 | 1 | +-------------+--------+---------+------------+--------+----------+ | ML-KEM-768 | 1184 | 2400 | 1088 | 32 | 3 | +-------------+--------+---------+------------+--------+----------+ | ML-KEM-1024 | 1568 | 2168 | 1568 | 32 | 5 | +-------------+--------+---------+------------+--------+----------+ Table 2: ML-KEM Parameter Sizes (in bytes) [MLKEM.SPEC] also allows to use a 64 bytes seed to represent the private key. 3.1.2. FrodoKEM FrodoKEM is a lattice-based KEM, whose security is based on the plain Learning with Errors (LWE) hardness assumption, unlike ML-KEM which is based on structured lattices. This makes FrodoKEM a more conservative KEM scheme. It is considered for standardization by ISO, and it is recommended by European security agencies. Each security level allows the choice between AES and SHAKE as the underlying symmetric primitive. The AES variant is beneficial on devices with AES hardware acceleration, while the SHAKE variant generally provides better performance if hardware acceleration is not available. The FrodoKEM specification is available at [FRODOKEM.SPEC]. Prabel, et al. Expires 3 January 2026 [Page 5] Internet-Draft PQC Algo Guidance July 2025 +=====================+======+=======+============+======+========+ | Scheme |Public|Private| Ciphertext |Shared|Claimed | | |Key |Key | |Secret|Security| | | | | | |Level | +=====================+======+=======+============+======+========+ | FrodoKEM-640-AES |9616 |19888 | 9720 |16 |1 | +---------------------+------+-------+------------+------+--------+ | FrodoKEM-640-SHAKE |9616 |19888 | 9720 |16 |1 | +---------------------+------+-------+------------+------+--------+ | FrodoKEM-976-AES |15632 |31296 | 15744 |24 |3 | +---------------------+------+-------+------------+------+--------+ | FrodoKEM-976-SHAKE |15632 |31296 | 15744 |24 |3 | +---------------------+------+-------+------------+------+--------+ | FrodoKEM-1344-AES |21520 |43088 | 21632 |32 |5 | +---------------------+------+-------+------------+------+--------+ | FrodoKEM-1344-SHAKE |21520 |43088 | 21632 |32 |5 | +---------------------+------+-------+------------+------+--------+ Table 3: FrodoKEM Parameter Sizes (in bytes) 3.1.3. Classic McEliece Classic McEliece is a conservative, code-based KEM, based on the original McEliece cryptosystem from 1978. It requires larger key sizes compared to the other KEMs discussed here, but relatively small ciphertext sizes. Each security level includes an 'f' variant that is more complex internally than the 'non-f' variant but enables faster key generation. It has withstood extensive cryptanalysis over several decades, and several European security agencies have expressed confidence in its security. It is considered for standardization by ISO. The Classic McEliece specification is available at [CLASSICMCELIECE.SPEC]. Prabel, et al. Expires 3 January 2026 [Page 6] Internet-Draft PQC Algo Guidance July 2025 +===========+=========+=========+============+========+==========+ | Scheme | Public | Private | Ciphertext | Shared | Claimed | | | Key | Key | | Secret | Security | | | | | | | Level | +===========+=========+=========+============+========+==========+ | Classic-M | 261120 | 6492 | 96 | 32 | 1 | | cEliece-3 | | | | | | | 48864 | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic- | 261120 | 6492 | 96 | 32 | 1 | | McEliece- | | | | | | | 348864f | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic-M | 524160 | 13608 | 156 | 32 | 3 | | cEliece-4 | | | | | | | 60896 | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic- | 524160 | 13608 | 156 | 32 | 3 | | McEliece- | | | | | | | 460896f | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic-M | 1044992 | 13932 | 208 | 32 | 5 | | cEliece-6 | | | | | | | 688128 | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic- | 1044992 | 13932 | 208 | 32 | 5 | | McEliece- | | | | | | | 6688128f | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic-M | 1047319 | 13948 | 194 | 32 | 5 | | cEliece-6 | | | | | | | 960119 | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic- | 1047319 | 13948 | 194 | 32 | 5 | | McEliece- | | | | | | | 6960119f | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic-M | 1357824 | 14120 | 208 | 32 | 5 | | cEliece-8 | | | | | | | 192128 | | | | | | +-----------+---------+---------+------------+--------+----------+ | Classic- | 1357824 | 14120 | 208 | 32 | 5 | | McEliece- | | | | | | | 8192128f | | | | | | +-----------+---------+---------+------------+--------+----------+ Table 4: Classic-McEliece Parameter Sizes (in bytes) Prabel, et al. Expires 3 January 2026 [Page 7] Internet-Draft PQC Algo Guidance July 2025 3.1.4. HQC HQC is a code-based KEM relying on the decisional Quasi-Cyclic Syndrome Decoding (QCSD) hardness assumption. HQC offers small public key and ciphertext sizes, although these are larger than those of ML-KEM. It will be standardized by NIST. The HQC specification is available at [HQC.SPEC]. +=========+========+=========+============+========+================+ | Scheme | Public | Private | Ciphertext | Shared | Claimed | | | Key | Key | | Secret | Security | | | | | | | Level | +=========+========+=========+============+========+================+ | HQC-128 | 2249 | 2305 | 4433 | 64 | 1 | +---------+--------+---------+------------+--------+----------------+ | HQC-192 | 4522 | 4586 | 8978 | 64 | 3 | +---------+--------+---------+------------+--------+----------------+ | HQC-256 | 7245 | 7317 | 14421 | 64 | 5 | +---------+--------+---------+------------+--------+----------------+ Table 5: HQC Parameter Sizes (in bytes) 3.1.5. NTRU NTRU is a structured lattice-based KEM. It has a long, well- established history and has been widely analyzed. It is considered for standardization by ISO. The NTRU specification is available at [NTRU.SPEC]. Prabel, et al. Expires 3 January 2026 [Page 8] Internet-Draft PQC Algo Guidance July 2025 +================+======+=========+============+========+==========+ | Scheme |Public| Private | Ciphertext | Shared | Claimed | | |Key | Key | | Secret | Security | | | | | | | Level | +================+======+=========+============+========+==========+ | ntruhps2048509 |699 | 935 | 699 | 32 | 1 | +----------------+------+---------+------------+--------+----------+ | ntruhps2048677 |930 | 1235 | 930 | 32 | 3 | +----------------+------+---------+------------+--------+----------+ | ntruhps4096821 |1230 | 1592 | 1230 | 32 | 5 | +----------------+------+---------+------------+--------+----------+ | ntruhrss701 |1138 | 1452 | 1138 | 32 | 3 | +----------------+------+---------+------------+--------+----------+ | ntruhrss1373 |2401 | 2983 | 2401 | 32 | 5 | +----------------+------+---------+------------+--------+----------+ Table 6: NTRU Parameter Sizes (in bytes) 3.2. Signature Scheme 3.2.1. ML-DSA ML-DSA, formerly known as CRYSTALS-Dilithium, is a structured lattice-based signature scheme, now standardized by NIST. The security of ML-DSA is based on the computational hardness of the Module Learning with Errors problem as well as the SelfTargetMSIS problem, a variant of the Module Short Integer Solution problem. European security agencies recommend at least Security Level 3. The NIST specification of ML-DSA is available at [MLDSA.SPEC]. +===========+============+=============+===========+================+ | Scheme | Public Key | Private | Signature | Claimed | | | | Key | | Security Level | +===========+============+=============+===========+================+ | ML-DSA-44 | 1312 | 2560 | 2420 | 2 | +-----------+------------+-------------+-----------+----------------+ | ML-DSA-65 | 1952 | 4032 | 3309 | 3 | +-----------+------------+-------------+-----------+----------------+ | ML-DSA-87 | 2592 | 4896 | 4627 | 5 | +-----------+------------+-------------+-----------+----------------+ Table 7: ML-DSA Parameter Sizes (in bytes) [MLDSA.SPEC] also allows to use a 32 bytes seed to represent the private key. Prabel, et al. Expires 3 January 2026 [Page 9] Internet-Draft PQC Algo Guidance July 2025 3.2.2. FN-DSA FN-DSA, formerly known as Falcon, is a lattice-based signature scheme that was selected by NIST for standardization. It relies on floating-point arithmetic, which is considered challenging to implement securely, especially with respect to side- channel attacks. The Falcon specification is available at [FNDSA.SPEC]. +====================+========+=========+===========+==========+ | Scheme | Public | Private | Signature | Claimed | | | Key | Key | | Security | | | | | | Level | +====================+========+=========+===========+==========+ | Falcon-512 | 897 | 1281 | 752 | 1 | +--------------------+--------+---------+-----------+----------+ | Falcon-1024 | 1793 | 2305 | 1462 | 5 | +--------------------+--------+---------+-----------+----------+ | Falcon-padded-512 | 897 | 1281 | 666 | 1 | +--------------------+--------+---------+-----------+----------+ | Falcon-padded-1024 | 1793 | 2305 | 1280 | 5 | +--------------------+--------+---------+-----------+----------+ Table 8: FN-DSA Parameter Sizes (in bytes) 3.2.3. SLH-DSA SLH-DSA, formerly known as SPHINCS+, is a stateless hash-based signature scheme now standardized by NIST. Each security level offers two possible hash function families (SHA-2 or SHAKE) and for both, two specific variants. The 's' variant has smaller signature sizes, while the 'f' variant has faster signature generation. The NIST specification of SLH-DSA is available at [SLHDSA.SPEC]. Prabel, et al. Expires 3 January 2026 [Page 10] Internet-Draft PQC Algo Guidance July 2025 +====================+========+=========+===========+==========+ | Scheme | Public | Private | Signature | Claimed | | | Key | Key | | Security | | | | | | Level | +====================+========+=========+===========+==========+ | SLH-DSA-SHA2-128s | 32 | 64 | 7856 | 1 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHAKE-128s | 32 | 64 | 7856 | 1 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHA2-128f | 32 | 64 | 17088 | 1 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHAKE-128f | 32 | 64 | 17088 | 1 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHA2-192s | 48 | 96 | 16224 | 3 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHAKE-192s | 48 | 96 | 16224 | 3 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHA2-192f | 48 | 96 | 35664 | 3 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHAKE-192f | 48 | 96 | 35664 | 3 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHA2-256s | 64 | 128 | 29762 | 5 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHAKE-256s | 64 | 128 | 29762 | 5 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHA2-256f | 64 | 128 | 49856 | 5 | +--------------------+--------+---------+-----------+----------+ | SLH-DSA-SHAKE-256f | 64 | 128 | 49856 | 5 | +--------------------+--------+---------+-----------+----------+ Table 9: SLH-DSA Parameter Sizes (in bytes) 3.2.4. LMS Leighton-Micali Signatures (LMS) is a stateful hash-based signature scheme that uses LM-OTS for one-time signatures, and is based on Merkle hash trees. It requires careful state management. [I-D.draft-ietf-pquip-hbs-state] provides guidance and security considerations on state management for stateful hash-based signature schemes. The NIST specification of LMS is available at [LMS.SPEC]. Prabel, et al. Expires 3 January 2026 [Page 11] Internet-Draft PQC Algo Guidance July 2025 3.2.4.1. LMS with SHA-256 The signatures' sizes for the LMS_SHA256_M32_H{5, 10, 15, 20, 25} signature scheme depends on the choice of the underlying LMOTS scheme and in particular on the value of the Winternitz parameter W. Therefore, the signatures' sizes of LMS_SHA256_M32_H{5, 10, 15, 20, 25} are given in a 4-elements array where values correspond to the value of W = 8, 4, 2, 1 in that order. Prabel, et al. Expires 3 January 2026 [Page 12] Internet-Draft PQC Algo Guidance July 2025 +=====================+========+============+===========+==========+ | Scheme | Public | Private | Signature | Claimed | | | Key | Key | | Security | | | | | | Level | +=====================+========+============+===========+==========+ | LMOTS_SHA256_N32_W1 | 56 | 8504 | 8516 | x | +---------------------+--------+------------+-----------+----------+ | LMOTS_SHA256_N32_W2 | 56 | 4280 | 4292 | x | +---------------------+--------+------------+-----------+----------+ | LMOTS_SHA256_N32_W4 | 56 | 2168 | 2180 | x | +---------------------+--------+------------+-----------+----------+ | LMOTS_SHA256_N32_W8 | 56 | 1112 | 1124 | x | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M32_H5 | 56 | 1796 | [1296, | 5 | | | | | 2352, | | | | | | 4464, | | | | | | 8688] | | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M32_H10 | 56 | 57348 | [1456, | 5 | | | | | 2512, | | | | | | 4624, | | | | | | 8848] | | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M32_H15 | 56 | 1835012 | [1616, | 5 | | | | | 2672, | | | | | | 4784, | | | | | | 9008] | | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M32_H20 | 56 | 58720260 | [1776, | 5 | | | | | 2832, | | | | | | 4944, | | | | | | 9168] | | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M32_H25 | 56 | 1879048196 | [1936, | 5 | | | | | 2992, | | | | | | 5104, | | | | | | 9328] | | +---------------------+--------+------------+-----------+----------+ Table 10: LMS with SHA256 Parameter Sizes (in bytes) Prabel, et al. Expires 3 January 2026 [Page 13] Internet-Draft PQC Algo Guidance July 2025 3.2.4.2. LMS with SHA-256/192 The signatures' sizes for the LMS_SHA256/192_M24_H{5, 10, 15, 20, 25} signature scheme depends on the choice of the underlying LMOTS scheme and in particular on the value of the Winternitz parameter W. Therefore, the signatures' sizes of LMS_SHA256/192_M24_H{5, 10, 15, 20, 25} are given in a 4-elements array where values correspond to the value of W = 8, 4, 2, 1 in that order. Prabel, et al. Expires 3 January 2026 [Page 14] Internet-Draft PQC Algo Guidance July 2025 +=====================+========+============+===========+==========+ | Scheme | Public | Private | Signature | Claimed | | | Key | Key | | Security | | | | | | Level | +=====================+========+============+===========+==========+ | LMOTS_SHA256_N24_W1 | 56 | 4824 | 4828 | x | +---------------------+--------+------------+-----------+----------+ | LMOTS_SHA256_N24_W2 | 56 | 2448 | 2452 | x | +---------------------+--------+------------+-----------+----------+ | LMOTS_SHA256_N24_W4 | 56 | 1248 | 1251 | x | +---------------------+--------+------------+-----------+----------+ | LMOTS_SHA256_N24_W8 | 56 | 648 | 652 | x | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M24_H5 | 56 | 1796 | [784, | 5 | | | | | 1384, | | | | | | 2584, | | | | | | 4960] | | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M24_H10 | 56 | 57348 | [904, | 5 | | | | | 1504, | | | | | | 2704, | | | | | | 5080] | | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M24_H15 | 56 | 1835012 | [1024, | 5 | | | | | 1624, | | | | | | 2824, | | | | | | 5200] | | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M24_H20 | 56 | 58720260 | [1144, | 5 | | | | | 1744, | | | | | | 2944, | | | | | | 5320] | | +---------------------+--------+------------+-----------+----------+ | LMS_SHA256_M24_H25 | 56 | 1879048196 | [1264, | 5 | | | | | 1864, | | | | | | 3064, | | | | | | 5440] | | +---------------------+--------+------------+-----------+----------+ Table 11: LMS with SHA256/192 Parameter Sizes (in bytes) Prabel, et al. Expires 3 January 2026 [Page 15] Internet-Draft PQC Algo Guidance July 2025 3.2.4.3. LMS with SHAKE256/256 The signatures' sizes for the LMS_SHA256_M32_H{5, 10, 15, 20, 25} signature scheme depends on the choice of the underlying LMOTS scheme and in particular on the value of the Winternitz parameter W. Therefore, the signatures' sizes of LMS_SHA256_M32_H{5, 10, 15, 20, 25} are given in a 4-elements array where values correspond to the value of W = 8, 4, 2, 1 in that order. Prabel, et al. Expires 3 January 2026 [Page 16] Internet-Draft PQC Algo Guidance July 2025 +====================+========+============+=============+==========+ | Scheme | Public | Private | Signature | Claimed | | | Key | Key | | Security | | | | | | Level | +====================+========+============+=============+==========+ | LMOTS_SHAKE_N32_W1 | 56 | 8504 | 8516 | x | +--------------------+--------+------------+-------------+----------+ | LMOTS_SHAKE_N32_W2 | 56 | 4280 | 4292 | x | +--------------------+--------+------------+-------------+----------+ | LMOTS_SHAKE_N32_W4 | 56 | 2168 | 2180 | x | +--------------------+--------+------------+-------------+----------+ | LMOTS_SHAKE_N32_W8 | 56 | 1112 | 1124 | x | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M32_H5 | 56 | 1796 | [1296, | 5 | | | | | 2352, | | | | | | 4464, | | | | | | 8688] | | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M32_H10 | 56 | 57348 | [1456, | 5 | | | | | 2512, | | | | | | 4624, | | | | | | 8848] | | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M32_H15 | 56 | 1835012 | [1616, | 5 | | | | | 2672, | | | | | | 4784, | | | | | | 9008] | | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M32_H20 | 56 | 58720260 | [1776, | 5 | | | | | 2832, | | | | | | 4944, | | | | | | 9168] | | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M32_H25 | 56 | 1879048196 | [1936, | 5 | | | | | 2992, | | | | | | 5104, | | | | | | 9328] | | +--------------------+--------+------------+-------------+----------+ Table 12: LMS with SHAKE256/256 Parameter Sizes (in bytes) Prabel, et al. Expires 3 January 2026 [Page 17] Internet-Draft PQC Algo Guidance July 2025 3.2.4.4. LMS with SHAKE256/192 The signatures' sizes for the LMS_SHA256/192_M24_H{5, 10, 15, 20, 25} signature scheme depends on the choice of the underlying LMOTS scheme and in particular on the value of the Winternitz parameter W. Therefore, the signatures' sizes of LMS_SHA256/192_M24_H{5, 10, 15, 20, 25} are given in a 4-elements array where values correspond to the value of W = 8, 4, 2, 1 in that order. Prabel, et al. Expires 3 January 2026 [Page 18] Internet-Draft PQC Algo Guidance July 2025 +====================+========+============+=============+==========+ | Scheme | Public | Private | Signature | Claimed | | | Key | Key | | Security | | | | | | Level | +====================+========+============+=============+==========+ | LMOTS_SHAKE_N24_W1 | 56 | 4824 | 4828 | x | +--------------------+--------+------------+-------------+----------+ | LMOTS_SHAKE_N24_W2 | 56 | 2448 | 2452 | x | +--------------------+--------+------------+-------------+----------+ | LMOTS_SHAKE_N24_W4 | 56 | 1248 | 1252 | x | +--------------------+--------+------------+-------------+----------+ | LMOTS_SHAKE_N24_W8 | 56 | 648 | 652 | x | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M24_H5 | 56 | 1796 | [784, | 5 | | | | | 1384, | | | | | | 2584, | | | | | | 4960] | | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M24_H10 | 56 | 57348 | [904, | 5 | | | | | 1504, | | | | | | 2704, | | | | | | 5080] | | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M24_H15 | 56 | 1835012 | [1024, | 5 | | | | | 1624, | | | | | | 2824, | | | | | | 5200] | | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M24_H20 | 56 | 58720260 | [1144, | 5 | | | | | 1744, | | | | | | 2944, | | | | | | 5320] | | +--------------------+--------+------------+-------------+----------+ | LMS_SHAKE_M24_H25 | 56 | 1879048196 | [1264, | 5 | | | | | 1864, | | | | | | 3064, | | | | | | 5440] | | +--------------------+--------+------------+-------------+----------+ Table 13: LMS with SHAKE256/192 Parameter Sizes (in bytes) 3.2.5. XMSS / XMSS^MT The eXtended Merkle Signature Scheme (XMSS) is a stateful hash-based signature scheme that uses WOTS+ for one-time signatures, and is based on Merkle hash trees. XMSS^MT is a variant that has multiple hash trees. Prabel, et al. Expires 3 January 2026 [Page 19] Internet-Draft PQC Algo Guidance July 2025 It requires careful state management. [I-D.draft-ietf-pquip-hbs-state] provides guidance and security considerations on state management for stateful hash-based signature schemes. The NIST specification of XMSS is available at [XMSS.SPEC]. +===========================+======+=======+===========+==========+ | Scheme |Public|Private| Signature | Claimed | | |Key |Key | | Security | | | | | | Level | +===========================+======+=======+===========+==========+ | XMSS-SHA2_10_256 |64 |1793 | 2500 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHA2_16_256 |64 |2093 | 2692 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHA2_20_256 |64 |2573 | 2820 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHA2_20/2_256 |64 |5998 | 4963 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHA2_20/4_256 |64 |10938 | 9251 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHA2_40/2_256 |64 |9600 | 5605 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHA2_40/4_256 |64 |15252 | 9893 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHA2_40/8_256 |64 |24516 | 18469 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHA2_60/3_256 |64 |16629 | 8392 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHA2_60/6_256 |64 |24507 | 14824 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHA2_60/12_256 |64 |38095 | 27688 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHA2_10_192 |48 |1053 | 1492 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHA2_16_192 |48 |1605 | 1636 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHA2_20_192 |48 |1973 | 1732 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHAKE256_10_256 |64 |1373 | 2500 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHAKE256_16_256 |64 |2093 | 2692 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHAKE256_20_256 |64 |2573 | 2820 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHAKE256_20/2_256 |64 |5998 | 4963 | 5 | +---------------------------+------+-------+-----------+----------+ Prabel, et al. Expires 3 January 2026 [Page 20] Internet-Draft PQC Algo Guidance July 2025 | XMSSMT-SHAKE256_20/4_256 |64 |10938 | 9251 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHAKE256_40/2_256 |64 |9600 | 5605 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHAKE256_40/4_256 |64 |15252 | 9893 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHAKE256_40/8_256 |64 |24516 | 18469 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHAKE256_60/3_256 |64 |24516 | 8392 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHAKE256_60/6_256 |64 |24507 | 14824 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSSMT-SHAKE256_60/12_256 |64 |38095 | 27688 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHAKE256_10_192 |48 |1053 | 1492 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHAKE256_16_192 |48 |1605 | 1636 | 5 | +---------------------------+------+-------+-----------+----------+ | XMSS-SHAKE256_20_192 |48 |1973 | 1732 | 5 | +---------------------------+------+-------+-----------+----------+ Table 14: XMSS Parameter Sizes (in bytes) 4. Security Properties 4.1. Quantum-Vulnerable Asymmetric Cryptography Table 15 gives a list of asymmetric cryptographic schemes that are vulnerable to quantum computers and are planned to be deprecated and/ or disallowed in the future by various organizations or security agencies. In particular, NIST provides deprecation and disallowance timelines in [IR.8547]. The EU PQC Workstream also published its roadmap for the transition to post-quantum cryptography in [EU.Roadmap]. It distinguishes between low, medium and high quantum risk levels, and recommends completing the PQC transition for high-risk use cases before 2031, for medium-risk use cases before 2036, and for low-risk use cases before 2036, as much as feasible. Prabel, et al. Expires 3 January 2026 [Page 21] Internet-Draft PQC Algo Guidance July 2025 +========+===========================+===================+ | Scheme | Hardness assumption | Disallowed (NIST) | +========+===========================+===================+ | ECDSA | Discrete Logarithm | after 2035 | +--------+---------------------------+-------------------+ | EdDSA | Discrete Logarithm | after 2035 | +--------+---------------------------+-------------------+ | RSA | Factorisation | after 2035 | +--------+---------------------------+-------------------+ | (EC)DH | Decisional Diffie Hellman | after 2035 | +--------+---------------------------+-------------------+ Table 15: Quantum-Vulnerable Asymmetric Cryptographic Schemes 4.2. Quantum-Safe Asymmetric Cryptography Table 16 gives a brief summary of the security properties of various KEM algorithms. +==========+======+===================+===========+==========+ | Scheme | SDO | Hardness | Security | Comments | | | | assumption | Model | | +==========+======+===================+===========+==========+ | ML-KEM | NIST | Module LWE | IND-CCA-2 | xxx | +----------+------+-------------------+-----------+----------+ | FrodoKEM | ISO | Unstructured LWE | IND-CCA2 | xxx | +----------+------+-------------------+-----------+----------+ | HQC | NIST | Decisional Quasi- | IND-CCA2 | xxx | | | | Cyclic Syndrome | | | | | | Decoding Problem | | | +----------+------+-------------------+-----------+----------+ | Classic | ISO | Syndrome Decoding | IND-CCA2 | xxx | | McEliece | | Problem, Goppa | | | | | | code recovery | | | +----------+------+-------------------+-----------+----------+ | NTRU | ISO | NTRU | IND-CCA2 | xxx | +----------+------+-------------------+-----------+----------+ Table 16: Propeties of KEM schemes FrodoKEM is believed to have conservative security compared to schemes based on structured lattices like ML-KEM or NTRU. Table 17 gives a summary of the security properties of different signature algorithms. Prabel, et al. Expires 3 January 2026 [Page 22] Internet-Draft PQC Algo Guidance July 2025 +=========+======+=================+==========+==================+ | Scheme | SDO | Hardness | Security | Comments | | | | assumption | Model | | +=========+======+=================+==========+==================+ | ML-DSA | NIST | Module LWE, | SUF-CMA | xxx | | | | SelfTargetMSIS | | | +---------+------+-----------------+----------+------------------+ | FN-DSA | NIST | SIS over NTRU | EUF-CMA | Uses floating | | | | lattices | | point arithmetic | +---------+------+-----------------+----------+------------------+ | SLH-DSA | NIST | Second-preimage | SUF-CMA | xxx | | | | resistance | | | +---------+------+-----------------+----------+------------------+ | LMS | NIST | Collision | EUF-CMA | Need state | | | | resistance | | management | +---------+------+-----------------+----------+------------------+ | XMSS | NIST | Collision | EUF-CMA | Need state | | | | resistance | | management | +---------+------+-----------------+----------+------------------+ Table 17: Propeties of signatures schemes Hash-based signature schemes such as SLH-DSA, LMS, and XMSS are believed to offer more conservative security compared to lattice- based schemes like ML-DSA or FN-DSA. 5. IANA Considerations This document has no IANA action. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References Prabel, et al. Expires 3 January 2026 [Page 23] Internet-Draft PQC Algo Guidance July 2025 [CLASSICMCELIECE.SPEC] "Classic McEliece: conservative code-based cryptography", October 2022, . [EU.Roadmap] EU PQC Workstream, "A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography", June 2025, . [FNDSA.SPEC] "Falcon: Fast-Fourier Lattice-based Compact Signatures over NTRU", October 2020, . [FRODOKEM.SPEC] "FrodoKEM: Learning With Errors Key Encapsulation", December 2024, . [HQC.SPEC] "Hamming Quasi-Cyclic (HQC)", February 2025, . [I-D.draft-ietf-pquip-hbs-state] Wiggers, T., Bashiri, K., Kölbl, S., Goodman, J., and S. Kousidis, "Hash-based Signatures: State and Backup Management", Work in Progress, Internet-Draft, draft-ietf- pquip-hbs-state-00, 17 June 2025, . [I-D.draft-ietf-pquip-pqt-hybrid-terminology-04] D, F., P, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", Work in Progress, Internet- Draft, draft-ietf-pquip-pqt-hybrid-terminology-04, 10 September 2024, . [IR.8547] National Institute of Standards and Technology (NIST), "Transition to Post-Quantum Cryptography Standards", November 2024, . Prabel, et al. Expires 3 January 2026 [Page 24] Internet-Draft PQC Algo Guidance July 2025 [LMS.SPEC] "Stateless Hash-Based Digital Signature Standard", August 2024, . [MLDSA.SPEC] "Module-Lattice-Based Digital Signature Standard", August 2024, . [MLKEM.SPEC] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", August 2024, . [NTRU.SPEC] "NTRU Key Encapsulation", March 2025, . [SLHDSA.SPEC] "Stateless Hash-Based Digital Signature Standard", August 2024, . [XMSS.SPEC] "Recommendation for Stateful Hash-Based Signature Schemes", October 2020, . Authors' Addresses Lucas Prabel Huawei Email: lucas.prabel@huawei.com Shuzhou Sun Huawei Email: sunshuzhou@huawei.com Guang Zeng Huawei Email: zengguang13@huawei.com Prabel, et al. Expires 3 January 2026 [Page 25] Internet-Draft PQC Algo Guidance July 2025 Guilin Wang Huawei Email: wang.guilin@huawei.com Prabel, et al. Expires 3 January 2026 [Page 26]