<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="no"?> <?rfc tocdepth="6"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc compact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info" docName="draft-fluhrer-lms-more-parm-sets-19" number="9858" consensus="true" obsoletes="" updates=""submissionType="IETF"submissionType="IRTF" xml:lang="en" tocInclude="true" tocDepth="6" symRefs="true" sortRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.14.0 --><front> <title abbrev="Additional HSS/LMS Signatures">Additional ParametersetsSets for HSS/LMS Hash-Based Signatures</title> <seriesInfoname="Internet-Draft" value="draft-fluhrer-lms-more-parm-sets-19"/>name="RFC" value="9858"/> <author fullname="Scott Fluhrer"initials="S"initials="S." surname="Fluhrer"> <organization>Cisco Systems</organization> <address> <postal> <street>170 West Tasman Drive</street> <city>San Jose</city> <region>CA</region><country>USA</country><country>United States of America</country> </postal> <email>sfluhrer@cisco.com</email> </address> </author> <author fullname="Quynh Dang"initials="Q"initials="Q." surname="Dang"> <organization>NIST</organization> <address> <postal> <street>100 Bureau Drive</street> <city>Gaithersburg</city> <region>MD</region><country>USA</country><country>United States of America</country> </postal> <email>quynh.dang@nist.gov</email> </address> </author> <datemonth="February" day="12"month="September" year="2025"/> <workgroup>Crypto Forum</workgroup> <!--Is[rfced] Please insert any keywords (beyond those that appear in the"Security" area applicable here?title) for use on https://www.rfc-editor.org/search. --><area> IRTF </area> <workgroup> Crypto Forum Research Group</workgroup> <abstract> <t><keyword>example</keyword> <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of RFC 5743 have been adhered to in this document. See https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1. --> <!-- [rfced] Please clarify "by defining parameter sets by including additional hash functions" in the first sentence below. Also, would it be helpful to update "These include hash functions that result" in the second sentence in one of the following ways? Or is the current correct? Original: This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. Perhaps: This document extends HSS/LMS (RFC 8554) by defining additional parameter sets and hash functions. The hash functions result in signatures with significantly smaller sizes than the signatures using the current parameter sets, and they should have sufficient security. Or: This document extends HSS/LMS (RFC 8554) by defining additional parameter sets and hash functions that result in signatures with significantly smaller sizes than the signatures using the current parameter sets and they should have sufficient security. --> <abstract> <t> This document extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller sizes than the signatures using the current parameter sets and should have sufficient security. </t> <t> This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. </t> </abstract> </front> <middle> <section numbered="true" toc="default"> <name>Introduction</name><t> Stateful<!-- [rfced] Please clarify "a set of parameter sets to". Original: What this draft explores is a set of parameter sets to the HSS/LMS (RFC8554) stateful hash based signature method that reduce the size of the signature significantly or rely on a hash function other than SHA-256 (to increase cryptodiversity). Perhaps: This document explores parameter sets for the HSS/LMS stateful hash-based signature method [RFC8554] that reduce the size of the signature significantly or rely on a hash function other than SHA-256 (to increase cryptodiversity). --> <t> Stateful hash-based signatures have small private and public keys, are efficient to compute, and are believed to have excellent security. One disadvantage is that the signatures they produce tend to be somewhat large (possibly1k - 4kbytes). What this draft1-4 kilobytes). This document exploresisa set of parameter setstofor the HSS/LMS(RFC8554)statefulhash basedhash-based signature method <xref target="RFC8554"/> that reduce the size of the signature significantly or rely on a hash function other than SHA-256 (to increase cryptodiversity). </t> <t> This document represents the consensus of the Crypto Forum Research Group (CFRG) in the IRTF. It is not an IETF product and is not a standard. </t> <t> According to official definitions and common usage, a Leighton-MicaliHash-Based Signatures (LMS for short)Signature (LMS) is a statefulhash basedhash-based signature scheme that is based on asingle levelsingle-level Merkle tree. The Hierarchical Signature System(HSS for short)(HSS) is a way of binding several LMS signatures together in a hierarchicalmanner,manner to increase the number of signatures available. Strictly speaking, all the signaturesthatdiscussed in this documentdiscussesare HSS signatures (even if the HSS signature consists of a single LMS signature). However, it is common to refer to these signatures asLMS signatures."LMS signatures". This document uses the termHSS/LMS"HSS/LMS" to cover both the pedantic and the common meanings. </t> <t> This document is intended to be compatible with the NIST document <xref target="NIST_SP_800-208" format="default"/>. </t> </section> <section anchor="hashfunctions" numbered="true" toc="default"> <name>Additional Hash Function Definitions</name><t><!-- [rfced] May we update "that will be used in Section 3 and Section 4" as follows? Original: This section defines three hash functions that will be used in Section 3 and Section 4. Perhaps: This section defines three hash functions that are used with the parameter sets defined in Sections 3 and 4. --> <t> This section defines three hash functions that are used in Sections <xref target="ldwm"format="default"/>format="counter"/> and <xref target="merkle"format="default"/>.format="counter"/>. These hash functionswill beare used where SHA-256 is used in the original parameter sets fromRFC 8554.<xref target="RFC8554"/>. The hash function used is specified by the parameter setwhichthat is selected. </t> <section numbered="true" toc="default"><name>192 bit<name>192-Bit Hash FunctionbasedBased on SHA-256</name> <t> This document defines aSHA-2 basedSHA-2-based hash function with a192 bit192-bit output. As such, we define SHA-256/192 as a truncated version of SHA-256 <xref target="FIPS180" format="default"/>. That is, it is the result of performing a SHA-256 operation to amessage,message and then omitting the final 64 bits of the output. Thisis theprocedurefound in FIPS 180-4 (section 7)for truncating the hash output to 192bits.bits is described in Section 7 of <xref target="FIPS180"/>. </t><t> The<t>The following test vectormay illustrate this: </t> <artworkillustrates this:</t> <sourcecode name=""type="" align="left" alt=""><![CDATA[type="test-vectors"><![CDATA[ SHA-256("abc") = ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad SHA-256/192("abc") = ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c]]></artwork>]]></sourcecode> <t> We use the same IV as the untruncated SHA-256, rather than defining a distinct one, so that we can use a standard SHA-256 hash implementation without modification. In addition, the fact that anyone gets partial knowledge of the SHA-256 hash of a message by examining the SHA-256/192 hash of the same message is not a concern for this application. Each message that is hashed is randomized. Any message being signed includes the C randomizer (a value that is selected by the signer and is included in thehash)hash), which varies per message. Therefore, signing the same message by SHA-256 and by SHA-256/192 will not result in the same value being hashed, and so the latter hash value is not a prefix of the former one. In addition, all hashes include the I identifier, which is included as a part of the signature process in <xref target="RFC8554"format="default"/> signature process.format="default"/>. This I identifier is selected randomly for each private key (and hence two keys will have different I values with high probability), and so two intermediate hashes computed as a part of signing with two HSS private keys (one with a SHA-256 parameter set and one with a SHA-256/192 parameter set) will also be distinct with high probability. </t> </section> <section numbered="true" toc="default"><name>256 bit<name>256-Bit Hash FunctionbasedBased on SHAKE256</name> <t> This document defines a SHAKE-based hash function with a256 bit256-bit output. As such, we define SHAKE256/256 to be the first 256 bits of the SHAKE256XOF.extendable-output function (XOF). That is, it is the result of performing a SHAKE-256 operation to amessage,message and then using the first 256 bits of output. SeeFIPS 202<xref target="FIPS202" format="default"/> for more detail. </t> </section> <section numbered="true" toc="default"><name>192 bit<name>192-Bit Hash FunctionbasedBased on SHAKE256</name> <t> This document defines a SHAKE-based hash function with a192 bit192-bit output. As such, we define SHAKE256/192 to be the first 192 bits of the SHAKE256 XOF. That is, it is the result of performing a SHAKE-256 operation to amessage,message and then using the first 192 bits of output. SeeFIPS 202<xref target="FIPS202" format="default"/> for more detail. </t> </section> </section> <section anchor="ldwm" numbered="true" toc="default"> <name>Additional LM-OTS Parameter Sets</name> <!-- [rfced] We recommend updating these sentences as follows. Please review and let us know your thoughts. Original: Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) parameters defined that use the above hashes: ... Here is a table with the Leighton-Micali (LM) parameters defined that use SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions: ... Here is a table that gives the space used by both the 256 bit parameter sets and the 192 bit parameter sets, for a range of plausible Winternitz parameters and tree heights: Perhaps: The table below defines the Leighton-Micali One-Time Signature (LM- OTS) parameters that use the hashes defined in Section 2: ... The table below defines the Leighton-Micali (LM) parameters that use the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions: ... The table below gives the space used by both the 256-bit and 192-bit parameter sets for a range of plausible Winternitz parameters and tree heights: --> <t> Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) parameters defined that use the above hashes: </t> <table anchor="ldwm_sig_table" align="center"> <thead> <tr> <th align="left">Parameter Set Name</th> <th align="center">H</th> <th align="right">n</th> <th align="left">w</th> <th align="right">p</th> <th align="right">ls</th> <th align="center">id</th> </tr> </thead> <tbody> <tr> <td align="left">LMOTS_SHA256_N24_W1</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="left">1</td> <td align="right">200</td> <td align="right">8</td> <td align="center">0x0005</td> </tr> <tr> <td align="left">LMOTS_SHA256_N24_W2</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="left">2</td> <td align="right">101</td> <td align="right">6</td> <td align="center">0x0006</td> </tr> <tr> <td align="left">LMOTS_SHA256_N24_W4</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="left">4</td> <td align="right">51</td> <td align="right">4</td> <td align="center">0x0007</td> </tr> <tr> <td align="left">LMOTS_SHA256_N24_W8</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="left">8</td> <td align="right">26</td> <td align="right">0</td> <td align="center">0x0008</td> </tr> <tr> <td align="left">LMOTS_SHAKE_N32_W1</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="left">1</td> <td align="right">265</td> <td align="right">7</td> <td align="center">0x0009</td> </tr> <tr> <td align="left">LMOTS_SHAKE_N32_W2</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="left">2</td> <td align="right">133</td> <td align="right">6</td> <td align="center">0x000a</td> </tr> <tr> <td align="left">LMOTS_SHAKE_N32_W4</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="left">4</td> <td align="right">67</td> <td align="right">4</td> <td align="center">0x000b</td> </tr> <tr> <td align="left">LMOTS_SHAKE_N32_W8</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="left">8</td> <td align="right">34</td> <td align="right">0</td> <td align="center">0x000c</td> </tr> <tr> <td align="left">LMOTS_SHAKE_N24_W1</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="left">1</td> <td align="right">200</td> <td align="right">8</td> <td align="center">0x000d</td> </tr> <tr> <td align="left">LMOTS_SHAKE_N24_W2</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="left">2</td> <td align="right">101</td> <td align="right">6</td> <td align="center">0x000e</td> </tr> <tr> <td align="left">LMOTS_SHAKE_N24_W4</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="left">4</td> <td align="right">51</td> <td align="right">4</td> <td align="center">0x000f</td> </tr> <tr> <td align="left">LMOTS_SHAKE_N24_W8</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="left">8</td> <td align="right">26</td> <td align="right">0</td> <td align="center">0x0010</td> </tr> </tbody> </table><ul empty="true"> <li> Parameter<dl newline="false" spacing="normal" indent="5"> <dt>Parameter SetName is the human readableName:</dt><dd>The human-readable name of the parameterset. </li> <li> H is theset.</dd> <dt>H:</dt><dd>The second-preimage-resistant cryptographic hash function used within this parameterset. </li> <li> n is theset.</dd> <dt>n:</dt><dd>The number of bytes of the output of the hashfunction. </li> <li> w is thefunction.</dd> <dt>w:</dt><dd>The width (in bits) of the Winternitz coefficients; that is, the number of bits from the hash or checksum that is used with a single Winternitz chain. It is a member of the set { 1, 2, 4,8 } </li> <li> p is the8 }. </dd> <dt>p:</dt><dd>The number of n-byte string elements that make up the LM-OTSsignature. </li> <li> ls is thesignature.</dd> <dt>ls:</dt><dd>The number of left-shift bits used in the checksum function Cksm (used by algorithm 2 ofRFC 8554). </li> <li> id is the<xref target="RFC8554"/>).</dd> <dt>id:</dt><dd>The IANA-defined identifier used to denote this specific parameter set, which appears in both public keys and signatures.</li> </ul></dd> </dl> <t> These values are additions to the entries in Table 1 ofRFC 8554.<xref target="RFC8554"/>. </t> <t> The SHA256_N24, SHAKE_N32, and SHAKE_N24 in the parameter setnamenames denote the SHA-256/192,SHAKE256/256SHAKE256/256, and SHAKE256/192 hash functions defined in <xref target="hashfunctions" format="default"/>. </t> <t> Remember that the C message randomizer (which is included in the signature) has the same size (n bytes) as the hash output, and so it shrinks from 32 bytes to 24 bytes for the parameter sets that use either SHA-256/192 or SHAKE256/192. </t> </section> <section anchor="merkle" numbered="true" toc="default"> <name>Additional LM Parameter Sets</name><t> Here<t>Here is a table with the Leighton-Micali (LM) parameters defined that use SHA-256/192,SHAKE256/256SHAKE256/256, and SHAKE256/192 hash functions: </t> <table anchor="lms_table" align="center"> <thead> <tr> <thalign="center">Parameteralign="left">Parameter Set Name</th> <th align="center">H</th> <th align="right">m</th> <th align="right">h</th> <th align="center">id</th> </tr> </thead> <tbody> <tr> <tdalign="center">LMS_SHA256_M24_H5</td>align="left">LMS_SHA256_M24_H5</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="right">5</td> <td align="center">0x000a</td> </tr> <tr> <tdalign="center">LMS_SHA256_M24_H10</td>align="left">LMS_SHA256_M24_H10</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="right">10</td> <td align="center">0x000b</td> </tr> <tr> <tdalign="center">LMS_SHA256_M24_H15</td>align="left">LMS_SHA256_M24_H15</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="right">15</td> <td align="center">0x000c</td> </tr> <tr> <tdalign="center">LMS_SHA256_M24_H20</td>align="left">LMS_SHA256_M24_H20</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="right">20</td> <td align="center">0x000d</td> </tr> <tr> <tdalign="center">LMS_SHA256_M24_H25</td>align="left">LMS_SHA256_M24_H25</td> <td align="center">SHA-256/192</td> <td align="right">24</td> <td align="right">25</td> <td align="center">0x000e</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M32_H5</td>align="left">LMS_SHAKE_M32_H5</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="right">5</td> <td align="center">0x000f</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M32_H10</td>align="left">LMS_SHAKE_M32_H10</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="right">10</td> <td align="center">0x0010</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M32_H15</td>align="left">LMS_SHAKE_M32_H15</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="right">15</td> <td align="center">0x0011</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M32_H20</td>align="left">LMS_SHAKE_M32_H20</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="right">20</td> <td align="center">0x0012</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M32_H25</td>align="left">LMS_SHAKE_M32_H25</td> <td align="center">SHAKE256/256</td> <td align="right">32</td> <td align="right">25</td> <td align="center">0x0013</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M24_H5</td>align="left">LMS_SHAKE_M24_H5</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="right">5</td> <td align="center">0x0014</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M24_H10</td>align="left">LMS_SHAKE_M24_H10</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="right">10</td> <td align="center">0x0015</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M24_H15</td>align="left">LMS_SHAKE_M24_H15</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="right">15</td> <td align="center">0x0016</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M24_H20</td>align="left">LMS_SHAKE_M24_H20</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="right">20</td> <td align="center">0x0017</td> </tr> <tr> <tdalign="center">LMS_SHAKE_M24_H25</td>align="left">LMS_SHAKE_M24_H25</td> <td align="center">SHAKE256/192</td> <td align="right">24</td> <td align="right">25</td> <td align="center">0x0018</td> </tr> </tbody> </table><ul empty="true"> <li> Parameter<dl newline="false" spacing="normal" indent="5"> <dt>Parameter SetName is the human readableName:</dt><dd>The human-readable name of the parameterset. </li> <li> H is theset.</dd> <dt>H:</dt><dd>The second-preimage-resistant cryptographic hash function used within this parameterset. </li> <li> m is the theset.</dd> <dt>m:</dt><dd>The size in bytes of the hash functionoutput. </li> <li> h is theoutput.</dd> <dt>h:</dt><dd>The height of the Merkletree. </li> <li> id is thetree.</dd> <dt>id:</dt><dd>The IANA-defined identifier used to denote this specific parameter set,andwhich appears in both public keys andsignatures. </li> </ul>signatures.</dd> </dl> <t> These values are additions to the entries in Table 2 ofRFC 8554.<xref target="RFC8554"/>. </t> <t> The SHA256_M24, SHAKE_M32, and SHAKE_M24 in the parameter setnamenames denote the SHA-256/192,SHAKE256/256SHAKE256/256, and SHAKE256/192 hash functions defined in <xref target="hashfunctions" format="default"/>. </t> </section> <section anchor="usage_within_lms" numbered="true" toc="default"> <name>Usage forthese additional hash functionsThese Additional Hash Functions within HSS</name> <t> To use the additional hash functions within HSS, one would use the appropriate LMOTS id from <xref target="ldwm_sig_table" format="default"/> and the appropriate LMS id from <xref target="lms_table"format="default"/>,format="default"/> and use that additional hash function when computing the hashes for key generation, signaturegenerationgeneration, and signature verification. </t> <t> Note that the size of the I Merkle tree identifier remains 16 bytes, independent of what hash function is used. </t> </section> <section numbered="true" toc="default"> <name>Parameter Set Selection</name> <t> This document, along with <xref target="RFC8554" format="default"/>, defines four hash functions for use withinHSS/LMS; namelyHSS/LMS: SHA-256, SHA-256/192,SHAKE256/256SHAKE256/256, and SHAKE256/192. The main reason one would select a hash with a192 bit192-bit output (either SHA-256/192 or SHAKE256/192) would be to reduce the signature size; this comes at the cost of reducing the securitymargin; howevermargin. However, the security should be sufficient for mostuses. Inuses.</t> <t>In contrast, there is no security or signature size difference between theSHA-256 basedSHA-256-based parameter sets (SHA-256 or SHA-256/192) versus theSHAKE basedSHAKE-based parameter sets (SHAKE256/256 orSHAKE256/192); theSHAKE256/192). The reason for selecting between the two would be based on practical considerations, for example, if the implementation happens to have an existing SHA-256 (or SHAKE) implementation or if one of the two happens to give better hashing performance on the platform. </t> </section> <section anchor="parm_set_comparison" numbered="true" toc="default"> <name>Comparisons of192 bit192-Bit and256 bit parameter sets</name>256-Bit Parameter Sets</name> <t> Switching to a192 bit192-bit hash affects the signature size, the computation time, and the security strength. It significantly reduces the signature size and somewhat reduces the computation time, at the cost of security strength. See <xref target="Security" format="default"/> for a discussion of the security strength. </t> <t> The impact on signature size and computation time is based on two effects: </t> <ol> <li> Each hash that appears in the signature is shorter. </li> <li> We need fewer Winternitz chains (because LM-OTS signs a shorter value). </li> </ol> <!-- [rfced] How may we revise the parenthetical here to improve clarity? Current: For signature length, both effects are relevant (because the signature consists of a series of hashes and each hash is shorter, and because we need fewer Winternitz chains, we need fewer hashes in each LM-OTS signature). Perhaps: For signature length, both effects are relevant. The first is relevant because the signature consists of a series of hashes and each hash is shorter. The second is relevant because when we need fewer Winternitz chains, we need fewer hashes in each LM-OTS signature. Or: For signature length, both effects are relevant (i.e., because the signature consists of a series of hashes and each hash is shorter and because we need fewer Winternitz chains and thus fewer hashes in each LM-OTS signature). --> <t> For signature length, both effects are relevant (because the signature consists of a series of hashes and each hash is shorter, and because we need fewer Winternitz chains, we need fewer hashes in each LM-OTS signature). </t> <t> For computation time (for both signature generation and verification), effect 1 is irrelevant (we still need to perform essentially the same hash computation),howeverbut effect 2 still applies. For example, with W=8, SHA-256 requires 34 Winternitz chains per LM-OTS signature, but SHA-256/192 requires only 26. Since the vast majority of time (for both signature generation and verification) is spent computing these Winternitz chains, this reduction in the number of chains gives us some performance improvement. </t> <t> Here is a table that gives the space used by both the256 bit parameter sets256-bit andthe 192 bit192-bit parametersets,sets for a range of plausible Winternitz parameters and tree heights: </t> <table anchor="measured_performance" align="center"> <thead> <tr> <th align="center">ParmSet</th> <th align="center">Winternitz</th> <thalign="center">256 bitalign="center">256-bit hash</th> <thalign="center">192 bitalign="center">192-bit hash</th> </tr> </thead> <tbody> <tr> <td align="center">15</td> <td align="center">4</td> <td align="center">2672</td> <td align="center">1624</td> </tr> <tr> <td align="center">15</td> <td align="center">8</td> <td align="center">1616</td> <td align="center">1024</td> </tr> <tr> <td align="center">20</td> <td align="center">4</td> <td align="center">2832</td> <td align="center">1744</td> </tr> <tr> <td align="center">20</td> <td align="center">8</td> <td align="center">1776</td> <td align="center">1144</td> </tr> <tr> <td align="center">15/10</td> <td align="center">4</td> <td align="center">5236</td> <td align="center">3172</td> </tr> <tr> <td align="center">15/10</td> <td align="center">8</td> <td align="center">3124</td> <td align="center">1972</td> </tr> <tr> <td align="center">15/15</td> <td align="center">4</td> <td align="center">5396</td> <td align="center">3292</td> </tr> <tr> <td align="center">15/15</td> <td align="center">8</td> <td align="center">3284</td> <td align="center">2092</td> </tr> <tr> <td align="center">20/10</td> <td align="center">4</td> <td align="center">5396</td> <td align="center">3292</td> </tr> <tr> <td align="center">20/10</td> <td align="center">8</td> <td align="center">3284</td> <td align="center">2092</td> </tr> <tr> <td align="center">20/15</td> <td align="center">4</td> <td align="center">5556</td> <td align="center">3412</td> </tr> <tr> <td align="center">20/15</td> <td align="center">8</td> <td align="center">3444</td> <td align="center">2212</td> </tr> </tbody> </table><t>ParmSet: this is the<dl spacing="normal" newline="false"> <dt>ParmSet:</dt><dd>The height of the Merkle tree(s), which is the parameter "h" from <xref target="lms_table" format="default"/>. Parameter sets listed as a single integer haveL=1,L=1 and consist of a single Merkle tree of that height; parameter sets with L=2 are listed as x/y, with x being the height of thetop leveltop-level Merkletree,tree and y being the bottomlevel. </t> <t> Winternitz: this is thelevel.</dd> <dt>Winternitz:</dt><dd>The Winternitz parameter used, which is the parameter "w" from <xref target="ldwm_sig_table" format="default"/>. For the tests that use multiple trees, this applies to all ofthem. </t> <t> 256 bit hash: thethem.</dd> <dt>256-bit hash:</dt><dd>The size in bytes of a signature, assuming that a256 bit256-bit hash is used in the signature (either SHA-256 orSHAKE256/256). </t> <t> 192 bit hash: theSHAKE256/256).</dd> <dt>192-bit hash:</dt><dd>The size in bytes of a signature, assuming that a192 bit192-bit hash is used in the signature (either SHA-256/192 orSHAKE256/192). </t>SHAKE256/192).</dd> </dl> <t>An examination of the signature sizes shows that the192 bit192-bit parameters consistently give a35% - 40%35-40% reduction in the size of the signature in comparison with the256 bit256-bit parameters. </t><t>For<!-- [rfced] Will readers understand what "reason 2 above" refers to? Original: For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192 bit hash (for reason 2 listed above). Perhaps: For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192-bit hash (for effect 2 listed above). Or: For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192-bit hash (for reason 2 listed in Section 6). --> <t>For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192-bit hash (for reason 2 listed above). The SHAKE256/192 signatures may have either a faster or slower computation, depending on the implementation speed of SHAKE versus SHA-256 hashes. </t> <t> TheSHAKE256/256 basedSHAKE256/256-based parameter sets give no space advantage (or disadvantage) over the existing SHA-256-based parameter sets; any performance delta would depend solely on the implementation and whether they can generate SHAKE hashes faster than SHA-256 ones. </t> </section> <section anchor="Security" numbered="true" toc="default"> <name>Security Considerations</name> <t> The strength of a signature that uses the SHA-256/192,SHAKE256/256SHAKE256/256, and SHAKE256/192 hash functions is based on the difficulty in finding preimages or second preimages to those hash functions. As shown in <xref target="Katz16" format="default"/>, if we assume that the hash function can be modeled as a random oracle, then the security of the system is at least 8N-1 bits (where N is the size of the hash output in bytes); this gives us a security level of 255 bits for SHAKE256/256 and 191 bits for SHA-256/192 and SHAKE256/192). That is, the strength of SHA-256/192 and SHAKE256/192 can be expected to be equivalent to the strength of AES-192, while the strength of SHAKE256/256 is equivalent to the strength of AES-256. If AES-192 and AES-256 areQuantum Resistant, soquantum-resistant, then we expect SHA-256/192,SHAKE256/192SHAKE256/192, and SHAKE256/256 to also be. </t> <t> If we look at this in a different way, we see that the case of SHAKE256/256 is essentially the same as the existingSHA-256 basedSHA-256-based signatures; the difficultly of finding preimages and second preimages is essentially the same, and so they have (barring unexpected cryptographical advances) essentially the same level of security. </t> <t> The case of SHA-256/192 and SHAKE256/192 requires closer analysis. </t> <t> For a classical(nonquantum)(non-quantum) computer, there is no known attack better than performing hashes of a large number of distinct preimages. Therefore, a successful attack has a high probability of requiring nearly2**1922<sup>192</sup> hash computations (for either SHA-256/192 or SHAKE256/192). These can be taken as the expected workeffort,effort and would appear to be completely infeasible in practice. </t><t> With<!-- [rfced] Would updating "will need to be performed, performing the computations on" to "will need to be performed on" make this sentence easier to follow? Original: For example, if the adversary is willing to wait for 2**64 times the time taken by a hash computation (which is over 50 years if a QuantumComputer,Computer can compute a hash in 0.1 nsec), this implies that a total of 2**(192-64) = 2**128 hash computations will need to be performed, performing the computations on 2**64 (18 quintillion) separate Quantum Computers, each of which computes 2**64 hash evaluations. Perhaps: For example, if the adversary is willing to wait for 2**64 times the time taken by a hash computation (which is over 50 years if a quantum computer can compute a hash in 0.1 nanoseconds), this implies that a total of 2**(192-64) = 2**128 hash computations will need to be performed on 2**64 (18 quintillion) separate quantum computers, each of which computes 2**64 hash evaluations. --> <t> In theory, an attacker with a quantum computer couldin theoryuse Grover's algorithm <xref target="Grover96" format="default"/> to reduce the expected complexity to circa 2**96 hash computations (for N=24). On the other hand, implementing Grover's algorithm with this number of hash computations would require performing circa 2**96 hash computations in succession, which will take more time than is likely to be acceptable to any attacker. To speed this up, the attacker would need to run a number of instances of Grover's algorithm in parallel. This would necessarily increase the total work effort required, and to anextentextent, that makes it likelyto beinfeasible. This is because if we limit the time taken by Grover's algorithm to 2**t steps (for t <= 96), then to attack a hash preimage problem of 192 bits, it requires a total of 2**(192-t) hashcomputations (rathercomputations, rather than the 2**(192/2) hash computations it would require if we did not limit the timetaken).taken. In other words, the hash preimage can be found in 2**t steps by using 2**(192-2t)Quantum Computersquantum computers (for t <= 96), with one of theQuantum Computersquantum computers finding the preimage. For example, if the adversary is willing to wait for 2**64 times the time taken by a hash computation (which is over 50 years if aQuantum Computerquantum computer can compute a hash in 0.1nsec),nanoseconds), this implies that a total of 2**(192-64) = 2**128 hash computations will need to be performed, performing the computations on 2**64 (18 quintillion) separateQuantum Computers,quantum computers, each of which computes 2**64 hash evaluations. </t> <t> Hence, we expect that HSS/LMS based on these hash functions is secure against both classical and quantum computers, even though, in both cases, the expected work effort is less (for the N=24 case) than against either SHA-256 or SHAKE256/256. </t> <t> SHA-256 is subject to a length extension attack. In this attack, if the attacker is given the hash value of an unknown message (and the messagelength)length), then the attacker can compute the hash of the message appended with certain strings (even though the attacker does not know the contents of the initial part of the modified message). This would appear to be irrelevant to HSS for two reasons: </t><ul spacing="compact"><ul> <li> For the initial message hash, the hash is entirely on public data.HenceHence, this attack is irrelevant, because the attacker could compute the hash of the message with appended data anyways. </li> <li> The rest of the hashes within HSS are fixedlength, and hencelength. Hence, there is no opportunity to perform length extension attacks.</li> </ul><t><!-- [rfced] Should "standard SHA256" here include a hyphen (i.e., "standard SHA-256")? Original: In addition, to perform a length extension attack on SHA-256/192, the attacker has to guess the 64 omitted bits (because the attack requires all 256 bits of the hash value); hence that is even less of a concern than it is for the standard SHA256. --> <t> In addition, to perform a length extension attack on SHA-256/192, the attacker has to guess the 64 omitted bits (because the attack requires all 256 bits of the hash value); hence, that is even less of a concern than it is for the standard SHA256. </t> <!-- [rfced] The text after the semicolon is a fragment. How may we update to connect this text to the rest of the sentence? Original: However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced; 128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192. Perhaps: However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced to 128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192. Or: However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced (128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192). --> <t> There is one corner case for which the security strength is reduced: if we need to assume that the signer will never deliberately generate a signaturewhichthat is valid for two different messages. HSS uses randomized hashing when signing a message. That is, when a message is being presented to be signed, the signer generates a random value C and includes that in what is prepended to the message. Because the attacker cannot predict this value, it is infeasible for anyone other than the signer to find a generic collision. That is, practically speaking, a signature that is valid for two colliding messages is feasible only if the signer signed both messages. For this to happen, a signer (that is, the one with the private key and who picks the random C value) would have to break the collision resistance of the hash function to generate those two colliding messages. Note that this does not apply to someone who submits the messages forsigning,signing; only the signer could perform this. This would result in a signature that would be valid for two different selected messages. This is a nonstandard assumption for signature schemes and is usually not a concern, as we assume that the signer is trusted to generate signatures for any message. However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced; 128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192. </t> <t> Some cryptographers have raised the possibility of amultitargetmulti-target attack (where the attacker has signatures from a large number of publickeys,keys and succeeds ifhethey can generate a forgery against any one of those public keys). While no such method of attack has been proposed, the possibility cannot be excluded; if there are a large number of public keys, it might be prudent to consider the possibility of some security loss with N=24. If there are 2**K public keys, this security loss cannot be more than K bits of security. </t> <section numbered="true" toc="default"> <name>Note on theversionVersion of SHAKE</name> <t>FIPS 202<xref target="FIPS202" format="default"/> defines both SHAKE128 and SHAKE256. This specification selects SHAKE256, even though itis,is less efficient for largemessages, less efficient.messages. The reason is that SHAKE128 has a low upper bound on the difficulty of finding preimages (due to the invertibility of its internal permutation), which would limit the strength of HSS/LMS (whose strength is based on the difficulty of finding preimages). Hence, we specify the use of SHAKE256, which has a considerably stronger preimage resistance. </t> </section> </section> <section> <name>IANAconsiderations</name> <t>Considerations</name> <!-- [rfced] Questions about IANAhas assigned the code points for allvalues a) Should theadditional parameter setsvalues inSection 3 (intheIANA "LM-OTS Signatures" registry) and"id" column inSection 4 (in the IANA "Leighton-Micali Signatures (LMS)" registry). These assignments are also included in NIST SP 800-208, but the IANA registrations refer to this document alone. </t> </section> <section> <name>Acknowledgements</name> <t> We would like to thank Carsten Bormann, Russ Housley, Andrey Jivsov, Mallory Knodel, Virendra Kumar, Thomas Pornin and Stanislav Smyshlyaev for their insightfulTables 1 andhelpful reviews. </t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S" surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used2 be updated tosignifyexactly match therequirementsvalues in thespecification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for"Numeric Identifier" column of theInternet Community, and requests discussion"LM-OTS Signatures" andsuggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3979" target="https://www.rfc-editor.org/info/rfc3979" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3979.xml"> <front> <title>Intellectual Property Rights in IETF Technology</title> <author fullname="S. Bradner" initials="S" role="editor" surname="Bradner"/> <date month="March" year="2005"/> <abstract> <t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed"Leighton-Micali Signatures (LMS)" registries inthe IETF are designedregard toensure that IETF working groupscapitalization andparticipants have as much information about any IPR constraints on a technical proposal as possible. The policiesleading zeroes? We understand that these hex values arealso intended to benefit the Internet community and the public at large, while respectingthelegitimate rightssame. Examples: "id" column ofIPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. ItTable 1: 0x0005 0x000a "Numeric Identifier" column of "LM-OTS Signatures" registry: 0x00000005 0x0000000A Links to registries: https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml#leighton-micali-signatures-1 https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml#lm-ots-signatures b) Some of these values alsodescribesappear in Appendix A but without theobjectives"0x" prefix. Please confirm that this is correct. Example: Appendix A: 0000000a "Numeric Identifier" column of "LM-OTS Signatures" registry: 0x0000000A c) In Appendix A, we believe thepolicies are designednames below should be updated as follows tomeet. This memo updates RFC 2026 and,align withRFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="RFC" value="3979"/> <seriesInfo name="DOI" value="10.17487/RFC3979"/> </reference> <reference anchor="RFC4879" target="https://www.rfc-editor.org/info/rfc4879" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4879.xml"> <front> <title>Clarification oftheThird Party Disclosure Procedureparameter set names inRFC 3979</title> <author fullname="T. Narten" initials="T" surname="Narten"/> <date month="April" year="2007"/> <abstract> <t>This document clarifiesTables 1 andupdates a single sentence2 (and inRFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made,theintention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="RFC" value="4879"/> <seriesInfo name="DOI" value="10.17487/RFC4879"/> </reference> <reference anchor="RFC5226" target="https://www.rfc-editor.org/info/rfc5226" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml"> <front> <title>Guidelines for Writing anIANAConsiderations Section in RFCs</title> <author fullname="T. Narten" initials="T" surname="Narten"/> <author fullname="H. Alvestrand" initials="H" surname="Alvestrand"/> <date month="May" year="2008"/> <abstract> <t>Many protocols make useregistries). Please confirm. Note that there are two instances ofidentifiers consistingofconstants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option typeeach inDHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided bytheInternet Assigned Numbers Authority (IANA).</t> <t>In order fordocument. Original: LMS type 00000014 # LMS_SHAKE256_N24_H5 LMOTS type 00000010 # LMOTS_SHAKE256_N24_W8 LMS type 0000000f # LMS_SHAKE256_N32_H5 LMOTS type 0000000c # LMOTS_SHAKE256_N32_W8 Perhaps: LMS type 00000014 # LMS_SHAKE_M24_H5 LMOTS type 00000010 # LMOTS_SHAKE_N24_W8 LMS type 0000000f # LMS_SHAKE_M32_H5 LMOTS type 0000000c # LMOTS_SHAKE_N32_W8 --> <t> IANAto manage a given namespace prudently, it needs guidelines describing the conditions under which new values can behas assignedor when modifications to existing values can be made. If IANA is expected to play a role inthemanagement of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelinescode points forauthors onthespecific text that must be includedparameter sets in <xref target="ldwm"/> indocuments that place demands on IANA.</t> <t>This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices fortheInternet Community, and requests discussion"LM-OTS Signatures" registry andsuggestions for improvements.</t> </abstract> </front> <seriesInfo name="RFC" value="5226"/> <seriesInfo name="DOI" value="10.17487/RFC5226"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <front> <title>Ambiguity of Uppercase vs Lowercasethe parameter sets inRFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B" surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used<xref target="merkle"/> inprotocol specifications. This document aims to reducetheambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC174"/> </reference> <reference anchor="RFC8554" target="https://www.rfc-editor.org/info/rfc8554" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8554.xml"> <front> <title>Leighton-Micali Hash-Based Signatures</title> <author fullname="D. McGrew" initials="D" surname="McGrew"/> <author fullname="M. Curcio" initials="M" surname="Curcio"/> <author fullname="S. Fluhrer" initials="S" surname="Fluhrer"/> <date month="April" year="2019"/> <abstract> <t>This note describes a digital-signature system based on cryptographic hash functions, following the seminal work"Leighton-Micali Signatures (LMS)" registry. These assignments are included in <xref target="NIST_SP_800-208"/>, but the IANA registrations only reference thisarea of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micalidocument. </t> </section> </middle> <back> <references> <name>References</name> <!-- [rfced] The following reference entries appeared in1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.</t> <t>This document is a product oftheCrypto Forum Research Group (CFRG)Normative References section but were not cited in theIRTF. This has been reviewed by many researchers, bothtext. We have removed them; however, if they should be cited in theresearch group and outside of it. The Acknowledgements section lists many of them.</t> </abstract> </front> <seriesInfo name="RFC" value="8554"/> <seriesInfo name="DOI" value="10.17487/RFC8554"/> </reference>text, please let us know where to include them. [RFC2119] [RFC3979] [RFC4879] [RFC5226] [RFC8174] --> <references> <name>Normative References</name> <!-- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3979.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4879.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8554.xml"/> <referenceanchor="FIPS180">anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf"> <front> <title>Secure HashStandard (SHS)</title>Standard</title> <author><organization>National<organization abbrev="NIST">National Institute of Standards and Technology</organization> </author> <datemonth="March" year="2012"/>month="August" year="2015"/> </front> <seriesInfoname="FIPS"name="NIST FIPS" value="180-4"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> </reference> <referenceanchor="FIPS202">anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf"> <front> <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title> <author><organization>National<organization abbrev="NIST">National Institute of Standards and Technology</organization> </author> <date month="August" year="2015"/> </front> <seriesInfoname="FIPS"name="NIST FIPS" value="202"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/> </reference> </references> <references> <name>Informative References</name> <!-- [rfced] FYI - For [Grover96], we found the following URL from the ACM Digital Library: https://dl.acm.org/doi/10.1145/237814.237866 We have updated this reference to match the information provided at this URL. Please let us know if you have any objections. Current: [Grover96] Grover, L., "A fast quantum mechanical algorithm for database search", Proceedings of the twenty-eighth annual ACM symposium on Theory of Computing (STOC '96), pp. 212-219, DOI 10.1145/237814.237866, July 1996, <https://doi.org/10.1145/237814.237866>. --> <reference anchor="Grover96"> <front> <title>A fast quantum mechanical algorithm for database search</title> <author surname="Grover"initials="L.K.">initials="L."> <organization/> </author> <date month="July" year="1996"/> </front><seriesInfo name="28th<refcontent>Proceedings of the twenty-eighth annual ACMSymposiumsymposium ontheTheory ofComputing" value="p. 212"/>Computing (STOC '96), pp. 212-219</refcontent> <seriesInfo name="DOI" value="10.1145/237814.237866"/> </reference> <reference anchor="Katz16"> <front> <title>Analysis of a Proposed Hash-Based Signature Standard</title> <author surname="Katz" initials="J."> <organization/> </author> <date year="2016"/> </front><seriesInfo name="SSR 2016: Security<refcontent>Security StandardisationResearch" value="pp. 261-273"/>Research (SSR 2016), Lecture Notes in Computer Science, vol. 10074, pp. 261-273</refcontent> <seriesInfo name="DOI" value="10.1007/978-3-319-49100-4_12"/> </reference> <reference anchor="NIST_SP_800-208"> <front> <title>Recommendation for Stateful Hash-Based Signature Schemes</title><author> <organization>National Institute of Standards and Technology</organization> </author><author fullname="David A. Cooper" surname="Cooper" initials="D."/> <author fullname="Daniel C. Apon" surname="Apon" initials="D."/> <author fullname="Quynh H. Dang" surname="Dang" initials="Q."/> <author fullname="Michael S. Davidson" surname="Davidson" initials="M."/> <author fullname="Morris J. Dworkin" surname="Dworkin" initials="M."/> <author fullname="Carl A. Miller" surname="Miller" initials="C."/> <date month="October" year="2020"/> </front> <refcontent>National Institute of Standards and Technology</refcontent> <seriesInfo name="NIST SP" value="800-208"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-208"/> </reference> </references> </references><section numbered="true" toc="default"> <name>Test Cases</name> <t><!-- [rfced] Appendix A a) Appendix A includes four test cases, not three as indicated in the sentence below. We updated as follows for accuracy. Please let us know any objections. Original: This section provides three test cases that can be used to verify or debug an implementation, one for each hash function. Updated: This appendix provides four test cases that can be used to verify or debug an implementation. b) FYI - Note that we used figure titles to label the test cases for clarity, even though we see that figure titles were not used in a similar appendix in RFC 8554. Let us know any concerns. c) For the ease of the reader, we suggest adding subsections to Appendix A for each test case. Let us know your thoughts. Current: Appendix A. Test Cases Perhaps: Appendix A. Test Cases A.1. Test Case 1 A.2. Test Case 2 A.3. Test Case 3 A.4. Test Case 4 If we update like this, we could also remove "Test Case 1", "Test Case 2", etc. from the figure titles if you wish. --> <section numbered="true" toc="default"> <name>Test Cases</name> <t> This appendix provides four test cases that can be used to verify or debug an implementation. This data is formatted with the name of the elements on theleft,left and the value of the elements on the right, in hexadecimal. The concatenation of all of the values within a public key or signature produces that public key or signature, and values that do not fit within a single line are listed across successive lines. </t><t keepWithNext="true">Test<figure> <name>Test Case 1 - Private Key forSHA-256/192</t>SHA-256/192</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- (note: procedure in Appendix A of [RFC8554] is used) SEED 000102030405060708090a0b0c0d0e0f 1011121314151617 I 202122232425262728292a2b2c2d2e2f -------------------------------------------- -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 1 - Public Key forSHA-256/192</t>SHA-256/192</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- HSS public key levels 00000001 -------------------------------------------- LMS type 0000000a # LMS_SHA256_M24_H5 LMOTS type 00000008 # LMOTS_SHA256_N24_W8 I 202122232425262728292a2b2c2d2e2f K 2c571450aed99cfb4f4ac285da148827 96618314508b12d2 -------------------------------------------- -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 1 - Message forSHA-256/192</t>SHA-256/192</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- Message 54657374206d65737361676520666f72 |Test message for| 205348413235362d3139320a | SHA-256/192.| -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 1 - Signature forSHA-256/192</t>SHA-256/192</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- HSS signature Nspk 00000000 sig[0]: -------------------------------------------- LMS signature q 00000005 -------------------------------------------- LMOTS signature LMOTS type 00000008 # LMOTS_SHA256_N24_W8 C 0b5040a18c1b5cabcbc85b047402ec62 94a30dd8da8fc3da y[0] e13b9f0875f09361dc77fcc4481ea463 c073716249719193 y[1] 614b835b4694c059f12d3aedd34f3db9 3f3580fb88743b8b y[2] 3d0648c0537b7a50e433d7ea9d6672ff fc5f42770feab4f9 y[3] 8eb3f3b23fd2061e4d0b38f832860ae7 6673ad1a1a52a900 y[4] 5dcf1bfb56fe16ff723627612f9a48f7 90f3c47a67f870b8 y[5] 1e919d99919c8db48168838cece0abfb 683da48b9209868b y[6] e8ec10c63d8bf80d36498dfc205dc45d 0dd870572d6d8f1d y[7] 90177cf5137b8bbf7bcb67a46f86f26c fa5a44cbcaa4e18d y[8] a099a98b0b3f96d5ac8ac375d8da2a7c 248004ba11d7ac77 y[9] 5b9218359cddab4cf8ccc6d54cb7e1b3 5a36ddc9265c0870 y[10] 63d2fc6742a7177876476a324b03295b fed99f2eaf1f3897 y[11] 0583c1b2b616aad0f31cd7a4b1bb0a51 e477e94a01bbb4d6 y[12] f8866e2528a159df3d6ce244d2b6518d 1f0212285a3c2d4a y[13] 927054a1e1620b5b02aab0c8c10ed48a e518ea73cba81fcf y[14] ff88bff461dac51e7ab4ca75f47a6259 d24820b9995792d1 y[15] 39f61ae2a8186ae4e3c9bfe0af2cc717 f424f41aa67f03fa y[16] edb0665115f2067a46843a4cbbd297d5 e83bc1aafc18d1d0 y[17] 3b3d894e8595a6526073f02ab0f08b99 fd9eb208b59ff631 y[18] 7e5545e6f9ad5f9c183abd043d5acd6e b2dd4da3f02dbc31 y[19] 67b468720a4b8b92ddfe7960998bb7a0 ecf2a26a37598299 y[20] 413f7b2aecd39a30cec527b4d9710c44 73639022451f50d0 y[21] 1c0457125da0fa4429c07dad859c846c bbd93ab5b91b01bc y[22] 770b089cfede6f651e86dd7c15989c8b 5321dea9ca608c71 y[23] fd862323072b827cee7a7e28e4e2b999 647233c3456944bb y[24] 7aef9187c96b3f5b79fb98bc76c3574d d06f0e95685e5b3a y[25] ef3a54c4155fe3ad817749629c30adbe 897c4f4454c86c49 -------------------------------------------- LMS type 0000000a # LMS_SHA256_M24_H5 path[0] e9ca10eaa811b22ae07fb195e3590a33 4ea64209942fbae3 path[1] 38d19f152182c807d3c40b189d3fcbea 942f44682439b191 path[2] 332d33ae0b761a2a8f984b56b2ac2fd4 ab08223a69ed1f77 path[3] 19c7aa7e9eee96504b0e60c6bb5c942d 695f0493eb25f80a path[4] 5871cffd131d0e04ffe5065bc7875e82 d34b40b69dd9f3c1 ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 2 - Private Key forSHAKE256/192</t>SHAKE256/192</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- (note: procedure in Appendix A of [RFC8554] is used) SEED 303132333435363738393a3b3c3d3e3f 4041424344454647 I 505152535455565758595a5b5c5d5e5f -------------------------------------------- -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 2 - Public Key forSHAKE256/192</t>SHAKE256/192</name> <artwork name="" type="" align="left" alt=""><![CDATA[ --------------------------------------------- HSS public key levels 00000001 -------------------------------------------- LMS type 00000014 # LMS_SHAKE256_N24_H5 LMOTS type 00000010 # LMOTS_SHAKE256_N24_W8 I 505152535455565758595a5b5c5d5e5f K db54a4509901051c01e26d9990e55034 7986da87924ff0b1 -------------------------------------------- -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 2 - Message forSHAKE256/192</t>SHAKE256/192</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- Message 54657374206d65737361676520666f72 |Test message for| 205348414b453235362d3139320a | SHAKE256/192.| -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 2 - Signature forSHAKE256/192</t>SHAKE256/192</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- HSS signature Nspk 00000000 sig[0]: -------------------------------------------- LMS signature q 00000006 -------------------------------------------- LMOTS signature LMOTS type 00000010 # LMOTS_SHAKE256_N24_W8 C 84219da9ce9fffb16edb94527c6d1056 5587db28062deac4 y[0] 208e62fc4fbe9d85deb3c6bd2c01640a ccb387d8a6093d68 y[1] 511234a6a1a50108091c034cb1777e02 b5df466149a66969 y[2] a498e4200c0a0c1bf5d100cdb97d2dd4 0efd3cada278acc5 y[3] a570071a043956112c6deebd1eb3a7b5 6f5f6791515a7b5f y[4] fddb0ec2d9094bfbc889ea15c3c7b9be a953efb75ed648f5 y[5] 35b9acab66a2e9631e426e4e99b733ca a6c55963929b77fe y[6] c54a7e703d8162e736875cb6a455d4a9 015c7a6d8fd5fe75 y[7] e402b47036dc3770f4a1dd0a559cb478 c7fb1726005321be y[8] 9d1ac2de94d731ee4ca79cff454c811f 46d11980909f047b y[9] 2005e84b6e15378446b1ca691efe491e a98acc9d3c0f785c y[10] aba5e2eb3c306811c240ba2280292382 7d582639304a1e97 y[11] 83ba5bc9d69d999a7db8f749770c3c04 a152856dc726d806 y[12] 7921465b61b3f847b13b2635a45379e5 adc6ff58a99b00e6 y[13] 0ac767f7f30175f9f7a140257e218be3 07954b1250c9b419 y[14] 02c4fa7c90d8a592945c66e86a76defc b84500b55598a199 y[15] 0faaa10077c74c94895731585c8f900d e1a1c675bd8b0c18 y[16] 0ebe2b5eb3ef8019ece3e1ea7223eb79 06a2042b6262b4aa y[17] 25c4b8a05f205c8befeef11ceff12825 08d71bc2a8cfa0a9 y[18] 9f73f3e3a74bb4b3c0d8ca2abd0e1c2c 17dafe18b4ee2298 y[19] e87bcfb1305b3c069e6d385569a4067e d547486dd1a50d6f y[20] 4a58aab96e2fa883a9a39e1bd45541ee e94efc32faa9a94b y[21] e66dc8538b2dab05aee5efa6b3b2efb3 fd020fe789477a93 y[22] afff9a3e636dbba864a5bffa3e28d13d 49bb597d94865bde y[23] 88c4627f206ab2b465084d6b780666e9 52f8710efd748bd0 y[24] f1ae8f1035087f5028f14affcc5fffe3 32121ae4f87ac5f1 y[25] eac9062608c7d87708f1723f38b23237 a4edf4b49a5cd3d7 -------------------------------------------- LMS type 00000014 # LMS_SHAKE256_N24_H5 path[0] dd4bdc8f928fb526f6fb7cdb944a7eba a7fb05d995b5721a path[1] 27096a5007d82f79d063acd434a04e97 f61552f7f81a9317 path[2] b4ec7c87a5ed10c881928fc6ebce6dfc e9daae9cc9dba690 path[3] 7ca9a9dd5f9f573704d5e6cf22a43b04 e64c1ffc7e1c442e path[4] cb495ba265f465c56291a902e62a461f 6dfda232457fad14 ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 3 - Private Key forSHAKE256/256</t>SHAKE256/256</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- (note: procedure in Appendix A of [RFC8554] is used) SEED 606162636465666768696a6b6c6d6e6f 707172737475767778797a7b7c7d7e7f I 808182838485868788898a8b8c8d8e8f -------------------------------------------- -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 3 - Public Key forSHAKE256/256</t>SHAKE256/256</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- HSS public key levels 00000001 -------------------------------------------- LMS type 0000000f # LMS_SHAKE256_N32_H5 LMOTS type 0000000c # LMOTS_SHAKE256_N32_W8 I 808182838485868788898a8b8c8d8e8f K 9bb7faee411cae806c16a466c3191a8b 65d0ac31932bbf0c2d07c7a4a36379fe -------------------------------------------- -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 3 - Message forSHAKE256/256</t>SHAKE256/256</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- Message 54657374206d657361676520666f7220 |Testmesage for |message for| 5348414b453235362d3235360a |SHAKE256/256.| -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 3 - Signature forSHAKE256/256</t>SHAKE256/256</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- HSS signature Nspk 00000000 sig[0]: -------------------------------------------- LMS signature q 00000007 -------------------------------------------- LMOTS signature LMOTS type 0000000c # LMOTS_SHAKE256_N32_W8 C b82709f0f00e83759190996233d1ee4f 4ec50534473c02ffa145e8ca2874e32b y[0] 16b228118c62b96c9c77678b33183730 debaade8fe607f05c6697bc971519a34 y[1] 1d69c00129680b67e75b3bd7d8aa5c8b 71f02669d177a2a0eea896dcd1660f16 y[2] 864b302ff321f9c4b8354408d0676050 4f768ebd4e545a9b0ac058c575078e6c y[3] 1403160fb45450d61a9c8c81f6bd69bd fa26a16e12a265baf79e9e233eb71af6 y[4] 34ecc66dc88e10c6e0142942d4843f70 a0242727bc5a2aabf7b0ec12a99090d8 y[5] caeef21303f8ac58b9f200371dc9e41a b956e1a3efed9d4bbb38975b46c28d5f y[6] 5b3ed19d847bd0a737177263cbc1a226 2d40e80815ee149b6cce2714384c9b7f y[7] ceb3bbcbd25228dda8306536376f8793 ecadd6020265dab9075f64c773ef97d0 y[8] 7352919995b74404cc69a6f3b469445c 9286a6b2c9f6dc839be76618f053de76 y[9] 3da3571ef70f805c9cc54b8e501a98b9 8c70785eeb61737eced78b0e380ded4f y[10] 769a9d422786def59700eef3278017ba bbe5f9063b468ae0dd61d94f9f99d5cc y[11] 36fbec4178d2bda3ad31e1644a2bcce2 08d72d50a7637851aa908b94dc437612 y[12] 0d5beab0fb805e1945c41834dd6085e6 db1a3aa78fcb59f62bde68236a10618c y[13] ff123abe64dae8dabb2e84ca705309c2 ab986d4f8326ba0642272cb3904eb96f y[14] 6f5e3bb8813997881b6a33cac0714e4b 5e7a882ad87e141931f97d612b84e903 y[15] e773139ae377f5ba19ac86198d485fca 97742568f6ff758120a89bf19059b8a6 y[16] bfe2d86b12778164436ab2659ba86676 7fcc435584125fb7924201ee67b535da y[17] f72c5cb31f5a0b1d926324c26e67d4c3 836e301aa09bae8fb3f91f1622b1818c y[18] cf440f52ca9b5b9b99aba8a6754aae2b 967c4954fa85298ad9b1e74f27a46127 y[19] c36131c8991f0cc2ba57a15d35c91cf8 bc48e8e20d625af4e85d8f9402ec44af y[20] bd4792b924b839332a64788a7701a300 94b9ec4b9f4b648f168bf457fbb3c959 y[21] 4fa87920b645e42aa2fecc9e21e000ca 7d3ff914e15c40a8bc533129a7fd3952 y[22] 9376430f355aaf96a0a13d13f2419141 b3cc25843e8c90d0e551a355dd90ad77 y[23] 0ea7255214ce11238605de2f000d2001 04d0c3a3e35ae64ea10a3eff37ac7e95 y[24] 49217cdf52f307172e2f6c7a2a4543e1 4314036525b1ad53eeaddf0e24b1f369 y[25] 14ed22483f2889f61e62b6fb78f5645b dbb02c9e5bf97db7a0004e87c2a55399 y[26] b61958786c97bd52fa199c27f6bb4d68 c4907933562755bfec5d4fb52f06c289 y[27] d6e852cf6bc773ffd4c07ee2d6cc55f5 7edcfbc8e8692a49ad47a121fe3c1b16 y[28] cab1cc285faf6793ffad7a8c341a49c5 d2dce7069e464cb90a00b2903648b23c y[29] 81a68e21d748a7e7b1df8a593f3894b2 477e8316947ca725d141135202a9442e y[30] 1db33bbd390d2c04401c39b253b78ce2 97b0e14755e46ec08a146d279c67af70 y[31] de256890804d83d6ec5ca3286f1fca9c 72abf6ef868e7f6eb0fddda1b040ecec y[32] 9bbc69e2fd8618e9db3bdb0af13dda06 c6617e95afa522d6a2552de15324d991 y[33] 19f55e9af11ae3d5614b564c642dbfec 6c644198ce80d2433ac8ee738f9d825e -------------------------------------------- LMS type 0000000f # LMS_SHAKE256_N32_H5 path[0] 71d585a35c3a908379f4072d070311db 5d65b242b714bc5a756ba5e228abfa0d path[1] 1329978a05d5e815cf4d74c1e547ec4a a3ca956ae927df8b29fb9fab3917a7a4 path[2] ae61ba57e5342e9db12caf6f6dbc5253 de5268d4b0c4ce4ebe6852f012b162fc path[3] 1c12b9ffc3bcb1d3ac8589777655e22c d9b99ff1e4346fd0efeaa1da044692e7 path[4] ad6bfc337db69849e54411df8920c228 a2b7762c11e4b1c49efb74486d3931ea ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 4 - Private Key forforSHA256/192 withW=4</t>W=4</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- (note: procedure in Appendix A of [RFC8554] is used) SEED 202122232425262728292a2b2c2d2e2f 3031323334353637 I 404142434445464748494a4b4c4d4e4f -------------------------------------------- -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 4 - Public Key forforSHA256/192 withW=4</t>W=4</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- HSS public key levels 00000001 -------------------------------------------- LMS type 0000000d # LMS_SHA256_M24_H20 LMOTS type 00000007 # LMOTS_SHA256_N24_W4 I 404142434445464748494a4b4c4d4e4f K 9c08a50d170406869892802ee4142fcd eac990f110c2460c -------------------------------------------- -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 4 - Message forforSHA256/192 withW=4</t>W=4</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- Message 54657374206d65737361676520666f72 |Test message for| 205348413235362f31393220773d34 | SHA256/192 w=4| -------------------------------------------- ]]></artwork><t keepWithNext="true">Test</figure> <figure> <name>Test Case 4 - Signature for SHA256/192 withW=4</t>W=4</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------------------------------------------- HSS signature Nspk 00000000 sig[0]: -------------------------------------------- LMS signature q 00000064 -------------------------------------------- LMOTS signature LMOTS type 00000007 # LMOTS_SHA256_N24_W4 C 853fa6e1a65fef076acd2485505b93be 9aeb2641e3d3805c y[0] 1887f26f4bcdb6ac0337b76fa5d66038 34287e010b20516f y[1] 7c336df2134c0a981f1ec2bb7baee516 e91e67d3bd16c8d9 y[2] 45a7f2be4fd84a604ae3743efc609ee0 e69572e9c6d4a682 y[3] 50e877b75d3cae63e9d5c15a32bb3cd1 7045f6b3e195284f y[4] dd1ee3cfbe18f1cbd06ef3e7af34b184 4d42dac453115a45 y[5] 07ed525cec120d054b403c61a7e5034f ac4be6ef5412d194 y[6] d4b6bbc0ae6cd3fe9993d583ee06f403 0bc832efec24d1f7 y[7] 13f5088731b91a98491fa3adf1b322bc e26df24c8415e3a4 y[8] 6bdfe07a6fd48e6d951515758cd64349 91098bf6949249fc y[9] a338ec235871dd564998d07d9b1b1b8d 644e657fee8039da y[10] 8fe195d129faddb12d543b86b0ab8cf6 f26c121783f3b828 y[11] d03f793b42909272f688e4ef6d46e82b dd1a02b1ff86c3b7 y[12] 9920b2e6f19faf75c623242f1f2c549f 84fb2f4c3ffead31 y[13] 20d97baea507467bb2da79f132bbe15b 596fdfcb70983107 y[14] ebca2597de9d55bd83bcae5c28a85259 dadb354859986e60 y[15] c8afa0b10bd08a8f9ed9b1ede3377075 fe0ae36349f7d2ed y[16] 7bfc9ece0d4cd6972059329419feaf3b 9a1045b6cfa4ae89 y[17] b1cea8950aea4af870d1a3a3909ebc5a 3013d6deb927abc0 y[18] f95093e83cb36a9c1d6f13add19268ac 7a0371f8335b0952 y[19] a57fdb0141d55d937dd6ebb08fee8a5c f426ac97d54ee7aa y[20] 17e6c57be5e62a52a6b1b986730d3a3a ad8a7d327ddf883e y[21] 6bc7b636eb2a5c4f2a635ae5bada5418 d43dfedb69c0a020 y[22] 9334fac89d420d6ad5a2e1df95d26a1b feb99a5e8455061b y[23] fdf2d6e8394caf8a4be699b8afa38e52 4d4053330af478f8 y[24] 5bf33d3ca3a35bc96987282bd513a8f6 a52db9ba36aa9088 y[25] 2b3bf573fa275449d8d49eb30bed2bb1 7a0ecc7d8a20807f y[26] 2ea3dd37acd46c713cc2ac9d01a20a30 d6832eef86a1e26d y[27] 1cad7761bf4130a6565572766026509d eeddaf46b605452b y[28] 218a4e137a7ce063b546a35c52510f0e a2cac879192ec443 y[29] e43b37c5ffa23da7a7fc254324a3de70 5c771794f10ea356 y[30] e5a747e5146fd804a47719803c185b38 0e34b8dcc8269c2b y[31] 073d86b2307cf90c6c3ef9271f2d53df 2579f0c4cfb632db y[32] 37a9025965f70b4616673228e98644be 6576417b7a97f104 y[33] 350259e7f697408cdf8cf81a3e774162 6ccdb87ad8531264 y[34] cb5ceb7c8c097cec505091a3ee3a826c 54f78169abc2e7d0 y[35] a318dac10250ba940e51e79a3f572fb3 2bf442be6fd81267 y[36] 946e6387f9a8c705d945c653f2684655 e3fa6b9ee311d8a0 y[37] 91bef9898292fa272fb8761f066c23d8 7aa10d67871cc541 y[38] 9c843b796855c51ad1272e9264acd203 5a82b12c2ddbc85a y[39] dfcd7c22366a36495349391dbf000106 4b8f6b28365445d7 y[40] 33e48f1b058a6cb3e71bbb8df3e90406 299894f4ca682943 y[41] ceeba410b33b07716ffc18d6eab75f2d 6372f1133605fa3c y[42] 3ed66f2d8f7c5abe59e87d4500965e34 7523d73cb356c144 y[43] 827aaa22b1c72a15293c7400e02aaefc f36f68a8246900e6 y[44] e6228e7ad19d1450c23434f1e45043dc 2b6db57f20d8f5b3 y[45] 44d4162aa651333287cd8bf8fac41c78 d61fe2929209bfe2 y[46] dc5a2f80205c043b22e540a29f0ea0a5 ff529e55bf1dfe42 y[47] 96fc4bb4ac2e875322ab115db479fe97 9d64f78409af4ec3 y[48] ad3b758fff83af1b9c48e90ca39366f4 26c2fb921df55c72 y[49] 786a9217723945a1ac1a66af7def4f8b 367001732cce0e5b y[50] ac91ac9d603807f8bab105b46d315d4c b88feb1c8686884b -------------------------------------------- LMS type 0000000d # LMS_SHA256_M24_H20 path[0] 13d1a8ef00c5811c15c4d774fdcf7515 5315aff53ebdff8f path[1] b6a54f12c165963dd5690cc9842b0e21 90afc5443497584c path[2] 832155599d00aced84bb3b59170396f7 db4fa84aa8577f76 path[3] cf9367d6e99d3d5be3555d7156b004f2 002f505681b1ad22 path[4] 9b9b46a666672aa8ee662c3a0456a9ad da7a44fbaca46789 path[5] 577dcd36dc5cdff34b864d0a32492a0a cbcaa6c011748f20 path[6] 5b91ab2ab84f2333fb3e3b9acaecdac3 8b58aa5f32e718e2 path[7] 25631ed6674cccb8c119acbd4992ab31 30a6e912deec5983 path[8] 5ab52fbc549430f8b403e4a2a51cc7f4 6fc143d365763aa1 path[9] 708fd25bcd657a790e54718d97090624 2a3b8a97dff18e91 path[10] a44c4ba818a8dd2d242251265b023b82 6077eb740f6682e6 path[11] c4ada2b85a67988d406132c2ad899099 e44cfe610c3a5af7 path[12] 0b406224411a59597e5dda0f31cd16c9 14b67e96141661f0 path[13] 074f43eb02273481bc324ded26c64f23 88559d8c8bd0ef8b path[14] 34ca4afebfac2a689b4246c264241488 dcf922350dc44f7b path[15] c09d57dc1126291b2318810e0f44801c 071e572fd032c780 path[16] f44c9503a4c03c37417dc96422ba0849 c37956f9fd5d33ea path[17] 4fcab84276effec652ca77d7d47ac93c 633d99e0a236f03d path[18] 5587d1990ffaef737fced1f5cdd8f373 844e9f316aad41a0 path[19] b12302639f83a2d74c9fe30d305a942b c0c30352a5e44dfb ]]></artwork> </figure> </section> <section numbered="false"> <name>Acknowledgements</name> <t>We would like to thank <contact fullname="Carsten Bormann"/>, <contact fullname="Russ Housley"/>, <contact fullname="Andrey Jivsov"/>, <contact fullname="Mallory Knodel"/>, <contact fullname="Virendra Kumar"/>, <contact fullname="Thomas Pornin"/>, and <contact fullname="Stanislav Smyshlyaev"/> for their insightful and helpful reviews. </t> </section> </back> <!-- [rfced] In Section 2.1, we updated <artwork> to <sourcecode type="test-vectors">. Please let us know any concerns. Also, please review each artwork element in Appendix A. Should these be tagged as sourcecode or another element? If these are updated to sourcecode, please let us know how/if to set the type attribute. The current list of preferred values for the "type" attribute for <sourcecode> is available here: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types If this list does not contain an applicable type, then feel free to suggest a new one. Also, it is acceptable to leave the "type" attribute not set. --> <!-- [rfced] Does "**" indicate superscript? Some examples: 2**192 2**96 2**t 2**(192-t) 2**(192/2) If so, would you like to make use of <sup> for superscript in this document? As an example, we updated "2**192" in the fourth paragraph of Section 8 to use <sup>. If this is acceptable, we will update the other instances; if you choose not to use <sup>, we will revert this change. Note: In the HTML and PDF, it appears as superscript. In the text output, <sup> generates a^b instead of a**b, which was used in the original document. --> <!-- [rfced] We updated "1k - 4kbytes" and "0.1 nsec" as follows for clarity. Let us know any concerns. Original: One disadvantage is that the signatures they produce tend to be somewhat large (possibly 1k - 4kbytes). ... (which is over 50 years if a Quantum Computer can compute a hash in 0.1 nsec) Updated: One disadvantage is that the signatures they produce tend to be somewhat large (possibly 1-4 kilobytes). ... (which is over 50 years, if a quantum computer can compute a hash in 0.1 nanoseconds) --> <!-- [rfced] Terminology a) The first two sentences below use "LM-OTS" and "LM", while the third sentence uses "LMOTS" and "LMS" when discussing Tables 1 and 2. Please review and let us know if updates are needed for consistency. Original: Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) parameters defined that use the above hashes: ... Here is a table with the Leighton-Micali (LM) parameters defined that use SHA-256/192, SHAKE256/256 SHAKE256/256, and SHAKE256/192 hash functions: ... To use the additional hash functions within HSS, one would use the appropriate LMOTS id from Table 1 and the appropriate LMS id from Table 2, ... b) Please also review the following (which appear in Appendix A) and let us know if any updates are needed to align with the choice for the question above. LMS type LMOTS type LMOTS signature c) Please review the the following and let us know if any updates are needed. These are used in RFC 8445, but we note that there is redundancy with "signature" when expanded (i.e., "Leighton-Micali Signature signature" and "Hierarchical Signature System signature"). LMS signature HSS signature --> <!-- [rfced] Abbreviations: a) FYI - We have added expansions for the following abbreviation(s) per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. extendable-output function (XOF) b) How may we expand "IV" in the following? As "Initialization Vector (IV)"? This the only instance of IV in the document. Original: We use the same IV as the untruncated SHA-256, rather than defining a distinct one, so that we can use a standard SHA-256 hash implementation without modification. Perhaps: We use the same initialization vector as the untruncated SHA-256, rather than defining a distinct one, so that we can use a standard SHA-256 hash implementation without modification. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>