rfc9858.original.xml   rfc9858.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info
<?rfc tocdepth="6"?> " docName="draft-fluhrer-lms-more-parm-sets-19" number="9858" consensus="true" o
<?rfc symrefs="yes"?> bsoletes="" updates="" submissionType="IRTF" xml:lang="en" tocInclude="true" toc
<?rfc sortrefs="yes"?> Depth="6" symRefs="true" sortRefs="true" version="3">
<?rfc compact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info
" docName="draft-fluhrer-lms-more-parm-sets-19" obsoletes="" updates="" submissi
onType="IETF" xml:lang="en" tocInclude="true" tocDepth="6" symRefs="true" sortRe
fs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.14.0 -->
<front> <front>
<title abbrev="Additional HSS/LMS Signatures">Additional Parameter sets for <title abbrev="Additional HSS/LMS Signatures">Additional Parameter Sets for
HSS/LMS Hash-Based Signatures</title> HSS/LMS Hash-Based Signatures</title>
<seriesInfo name="Internet-Draft" value="draft-fluhrer-lms-more-parm-sets-19 <seriesInfo name="RFC" value="9858"/>
"/> <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<author fullname="Scott Fluhrer" initials="S" surname="Fluhrer">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>170 West Tasman Drive</street> <street>170 West Tasman Drive</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>sfluhrer@cisco.com</email> <email>sfluhrer@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Quynh Dang" initials="Q" surname="Dang"> <author fullname="Quynh Dang" initials="Q." surname="Dang">
<organization>NIST</organization> <organization>NIST</organization>
<address> <address>
<postal> <postal>
<street>100 Bureau Drive</street> <street>100 Bureau Drive</street>
<city>Gaithersburg</city> <city>Gaithersburg</city>
<region>MD</region> <region>MD</region>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>quynh.dang@nist.gov</email> <email>quynh.dang@nist.gov</email>
</address> </address>
</author> </author>
<date month="February" day="12" year="2025"/> <date month="September" year="2025"/>
<!-- Is the "Security" area applicable here? -->
<area> IRTF </area> <workgroup>Crypto Forum</workgroup>
<workgroup> Crypto Forum Research Group</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<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 set
s
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 set
s
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> <abstract>
<t> <t>
This note extends HSS/LMS (RFC 8554) by defining parameter sets by includi ng This document extends HSS/LMS (RFC 8554) by defining parameter sets by inc luding
additional hash functions. These include hash functions that result in si gnatures with significantly additional hash functions. These include hash functions that result in si gnatures with significantly
smaller size than the signatures using the current parameter sets, and sho uld smaller sizes than the signatures using the current parameter sets and sho uld
have sufficient security. have sufficient security.
</t> </t>
<t> <t>
This document is a product of the Crypto Forum Research Group (CFRG) in th e IRTF. This document is a product of the Crypto Forum Research Group (CFRG) in th e IRTF.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<!-- [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> <t>
Stateful hash based signatures have small private and public keys, Stateful hash-based signatures have small private and public keys,
are efficient to compute, and are believed to have excellent security. are efficient to compute, and are believed to have excellent security.
One disadvantage is that the signatures they produce tend to be somewhat One disadvantage is that the signatures they produce tend to be somewhat
large (possibly 1k - 4kbytes). large (possibly 1-4 kilobytes).
What this draft explores is a set of parameter sets to the HSS/LMS (RFC8554) This document explores a set of parameter sets for the HSS/LMS
stateful hash based signature method that reduce the size of the signature stateful hash-based signature method <xref target="RFC8554"/> that reduce the si
ze of the signature
significantly or rely on a hash function other than SHA-256 (to increase significantly or rely on a hash function other than SHA-256 (to increase
cryptodiversity). cryptodiversity).
</t> </t>
<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. 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>
<t> <t>
According to official definitions and common usage, Leighton-Micali Hash-Based S According to official definitions and common usage, a Leighton-Micali Signature
ignatures (LMS for short) is a stateful hash based signature scheme that is base (LMS) is a stateful hash-based signature scheme that is based on a single-level
d on a single level Merkle tree. Merkle tree.
Hierarchical Signature System (HSS for short) is a way of binding several LMS si The Hierarchical Signature System (HSS) is a way of binding several LMS signatur
gnatures together in a hierarchical manner, to increase the number of signatures es together in a hierarchical manner to increase the number of signatures availa
available. ble.
Strictly speaking, all the signatures that this document discusses are HSS signa Strictly speaking, all the signatures discussed in this document are HSS signatu
tures (even if the HSS signature consists of a single LMS signature). res (even if the HSS signature consists of a single LMS signature).
However, it is common to refer to these signatures as LMS signatures. However, it is common to refer to these signatures as "LMS signatures".
This document uses the term HSS/LMS to cover both the pedantic and the common me This document uses the term "HSS/LMS" to cover both the pedantic and the common
anings. meanings.
</t> </t>
<t> <t>
This document is intended to be compatible with the NIST document <xref target=" NIST_SP_800-208" format="default"/>. This document is intended to be compatible with the NIST document <xref target=" NIST_SP_800-208" format="default"/>.
</t> </t>
</section> </section>
<section anchor="hashfunctions" numbered="true" toc="default"> <section anchor="hashfunctions" numbered="true" toc="default">
<name>Additional Hash Function Definitions</name> <name>Additional Hash Function Definitions</name>
<t>
This section defines three hash functions that will be used in <xref target="ldw <!-- [rfced] May we update "that will be used in Section 3 and Section 4" as
m" format="default"/> and <xref target="merkle" format="default"/>. follows?
These hash functions will be used where SHA-256 is used in the original paramete
r sets from RFC 8554. Original:
The hash function used is specified by the parameter set which is selected. 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="counter"/> and <xref target="merkle" format="counter"/>.
These hash functions are used where SHA-256 is used in the original parameter se
ts from <xref target="RFC8554"/>.
The hash function used is specified by the parameter set that is selected.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>192 bit Hash Function based on SHA-256</name> <name>192-Bit Hash Function Based on SHA-256</name>
<t> <t>
This document defines a SHA-2 based hash function with a 192 bit output. This document defines a SHA-2-based hash function with a 192-bit output.
As such, we define SHA-256/192 as a truncated version of SHA-256 <xref target="F IPS180" format="default"/>. As such, we define SHA-256/192 as a truncated version of SHA-256 <xref target="F IPS180" format="default"/>.
That is, it is the result of performing a SHA-256 That is, it is the result of performing a SHA-256
operation to a message, and then omitting the final 64 bits of the output. operation to a message and then omitting the final 64 bits of the output.
This is the procedure found in FIPS 180-4 (section 7) for truncating the hash ou This procedure for truncating the hash output to 192 bits is described in Sectio
tput to 192 bits. n 7 of <xref target="FIPS180"/>.
</t>
<t>
The following test vector may illustrate this:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <t>The following test vector illustrates this:</t>
<sourcecode name="" type="test-vectors"><![CDATA[
SHA-256("abc") = ba7816bf 8f01cfea 414140de 5dae2223 SHA-256("abc") = ba7816bf 8f01cfea 414140de 5dae2223
b00361a3 96177a9c b410ff61 f20015ad b00361a3 96177a9c b410ff61 f20015ad
SHA-256/192("abc") = ba7816bf 8f01cfea 414140de 5dae2223 SHA-256/192("abc") = ba7816bf 8f01cfea 414140de 5dae2223
b00361a3 96177a9c b00361a3 96177a9c
]]></artwork> ]]></sourcecode>
<t> <t>
We use the same IV as the untruncated SHA-256, rather than defining a distinct o ne, We use the same IV as the untruncated SHA-256, rather than defining a distinct o ne,
so that we can use a standard SHA-256 hash implementation without modification. 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 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 of a message by examining the SHA-256/192 hash of the same message is
not a concern for this application. not a concern for this application.
Each message that is hashed is randomized. Any message being signed includes 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 the hash) the C randomizer (a value that is selected by the signer and is included in the hash),
which varies per message. which varies per message.
Therefore, signing the same message by SHA-256 and by SHA-256/192 will not 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 pre fix of the former one. result in the same value being hashed, and so the latter hash value is not a pre fix of the former one.
In addition, all hashes include the I identifier, which is included as a part of the <xref target="RFC8554" format="default"/> signature process. In addition, all hashes include the I identifier, which is included as a part of the signature process in <xref target="RFC8554" 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 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 ke ys (one with a SHA-256 parameter set and one a SHA-256/192 parameter set) will a lso be distinct with high probability. so two intermediate hashes computed as a part of signing with two HSS private ke ys (one with a SHA-256 parameter set and one with a SHA-256/192 parameter set) w ill also be distinct with high probability.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>256 bit Hash Function based on SHAKE256</name> <name>256-Bit Hash Function Based on SHAKE256</name>
<t> <t>
This document defines a SHAKE-based hash function with a 256 bit output. This document defines a SHAKE-based hash function with a 256-bit output.
As such, we define SHAKE256/256 to be the first 256 bits of the SHAKE256 XOF. As such, we define SHAKE256/256 to be the first 256 bits of the SHAKE256 extenda
That is, it is the result of performing a SHAKE-256 operation to a message, and ble-output function (XOF).
then using the first 256 bits of output. That is, it is the result of performing a SHAKE-256 operation to a message and t
See FIPS 202 <xref target="FIPS202" format="default"/> for more detail. hen using the first 256 bits of output.
See <xref target="FIPS202" format="default"/> for more detail.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>192 bit Hash Function based on SHAKE256</name> <name>192-Bit Hash Function Based on SHAKE256</name>
<t> <t>
This document defines a SHAKE-based hash function with a 192 bit output. This document defines a SHAKE-based hash function with a 192-bit output.
As such, we define SHAKE256/192 to be the first 192 bits of the SHAKE256 XOF. 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 a message, and That is, it is the result of performing a SHAKE-256 operation to a message and t
then using the first 192 bits of output. hen using the first 192 bits of output.
See FIPS 202 <xref target="FIPS202" format="default"/> for more detail. See <xref target="FIPS202" format="default"/> for more detail.
</t> </t>
</section> </section>
</section> </section>
<section anchor="ldwm" numbered="true" toc="default"> <section anchor="ldwm" numbered="true" toc="default">
<name>Additional LM-OTS Parameter Sets</name> <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> <t>
Here is a table with the Leighton-Micali One-Time Signature (LM-OTS) parameters Here is a table with the Leighton-Micali One-Time Signature (LM-OTS)
defined that use the above hashes: parameters defined that use the above hashes:
</t> </t>
<table anchor="ldwm_sig_table" align="center"> <table anchor="ldwm_sig_table" align="center">
<thead> <thead>
<tr> <tr>
<th align="left">Parameter Set Name</th> <th align="left">Parameter Set Name</th>
<th align="center">H</th> <th align="center">H</th>
<th align="right">n</th> <th align="right">n</th>
<th align="left">w</th> <th align="left">w</th>
<th align="right">p</th> <th align="right">p</th>
<th align="right">ls</th> <th align="right">ls</th>
skipping to change at line 274 skipping to change at line 367
<td align="left">LMOTS_SHAKE_N24_W8</td> <td align="left">LMOTS_SHAKE_N24_W8</td>
<td align="center">SHAKE256/192</td> <td align="center">SHAKE256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="left">8</td> <td align="left">8</td>
<td align="right">26</td> <td align="right">26</td>
<td align="right">0</td> <td align="right">0</td>
<td align="center">0x0010</td> <td align="center">0x0010</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul empty="true">
<li> Parameter Set Name is the human readable name of the parameter set. </li <dl newline="false" spacing="normal" indent="5">
> <dt>Parameter Set Name:</dt><dd>The human-readable name of the parameter set.<
<li> H is the second-preimage-resistant cryptographic hash function used with /dd>
in this parameter set. </li> <dt>H:</dt><dd>The second-preimage-resistant cryptographic hash function used
<li> n is the number of bytes of the output of the hash function. </li> within this parameter set.</dd>
<li> w is the width (in bits) of the Winternitz coefficients; that is, <dt>n:</dt><dd>The number of bytes of the output of the hash function.</dd>
the number of bits from the hash or checksum that is used with a <dt>w:</dt><dd>The width (in bits) of the Winternitz coefficients; that
single Winternitz chain. It is a member of the set is, the number of bits from the hash or checksum that is used with a single
{ 1, 2, 4, 8 } </li> Winternitz chain. It is a member of the set { 1, 2, 4, 8&nbsp;}. </dd>
<li> p is the number of n-byte string elements that make up the LM-OTS <dt>p:</dt><dd>The number of n-byte string elements that make up the
signature. </li> LM-OTS signature.</dd>
<li> ls is the number of left-shift bits used in the checksum function <dt>ls:</dt><dd>The number of left-shift bits used in the checksum
Cksm (used by algorithm 2 of RFC 8554). </li> function Cksm (used by algorithm 2 of <xref target="RFC8554"/>).</dd>
<li> id is the IANA-defined identifier used to denote this specific parameter <dt>id:</dt><dd>The IANA-defined identifier used to denote this specific
set, which appears in parameter set, which appears in both public keys and signatures. </dd>
both public keys and signatures. </li> </dl>
</ul>
<t> <t>
These values are additions to the entries in Table 1 of RFC 8554. These values are additions to the entries in Table 1 of <xref target="RFC8554"/> .
</t> </t>
<t> <t>
The SHA256_N24, SHAKE_N32, SHAKE_N24 in the parameter set name denote the The SHA256_N24, SHAKE_N32, and SHAKE_N24 in the parameter set names denote the
SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions defined in <xref targe SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions defined in <xref targ
t="hashfunctions" format="default"/>. et="hashfunctions" format="default"/>.
</t> </t>
<t> <t>
Remember that the C message randomizer (which is included in the signature) has the same size (n bytes) as the hash output, 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 eith er SHA-256/192 or SHAKE256/192. and so it shrinks from 32 bytes to 24 bytes for the parameter sets that use eith er SHA-256/192 or SHAKE256/192.
</t> </t>
</section> </section>
<section anchor="merkle" numbered="true" toc="default"> <section anchor="merkle" numbered="true" toc="default">
<name>Additional LM Parameter Sets</name> <name>Additional LM Parameter Sets</name>
<t>
Here is a table with the Leighton-Micali (LM) parameters defined that use SHA-25 <t>Here is a table with the Leighton-Micali (LM) parameters defined that
6/192, SHAKE256/256 and SHAKE256/192 hash functions: use SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions:
</t> </t>
<table anchor="lms_table" align="center"> <table anchor="lms_table" align="center">
<thead> <thead>
<tr> <tr>
<th align="center">Parameter Set Name</th> <th align="left">Parameter Set Name</th>
<th align="center">H</th> <th align="center">H</th>
<th align="right">m</th> <th align="right">m</th>
<th align="right">h</th> <th align="right">h</th>
<th align="center">id</th> <th align="center">id</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">LMS_SHA256_M24_H5</td> <td align="left">LMS_SHA256_M24_H5</td>
<td align="center">SHA-256/192</td> <td align="center">SHA-256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">5</td> <td align="right">5</td>
<td align="center">0x000a</td> <td align="center">0x000a</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHA256_M24_H10</td> <td align="left">LMS_SHA256_M24_H10</td>
<td align="center">SHA-256/192</td> <td align="center">SHA-256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">10</td> <td align="right">10</td>
<td align="center">0x000b</td> <td align="center">0x000b</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHA256_M24_H15</td> <td align="left">LMS_SHA256_M24_H15</td>
<td align="center">SHA-256/192</td> <td align="center">SHA-256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">15</td> <td align="right">15</td>
<td align="center">0x000c</td> <td align="center">0x000c</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHA256_M24_H20</td> <td align="left">LMS_SHA256_M24_H20</td>
<td align="center">SHA-256/192</td> <td align="center">SHA-256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">20</td> <td align="right">20</td>
<td align="center">0x000d</td> <td align="center">0x000d</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHA256_M24_H25</td> <td align="left">LMS_SHA256_M24_H25</td>
<td align="center">SHA-256/192</td> <td align="center">SHA-256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">25</td> <td align="right">25</td>
<td align="center">0x000e</td> <td align="center">0x000e</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M32_H5</td> <td align="left">LMS_SHAKE_M32_H5</td>
<td align="center">SHAKE256/256</td> <td align="center">SHAKE256/256</td>
<td align="right">32</td> <td align="right">32</td>
<td align="right">5</td> <td align="right">5</td>
<td align="center">0x000f</td> <td align="center">0x000f</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M32_H10</td> <td align="left">LMS_SHAKE_M32_H10</td>
<td align="center">SHAKE256/256</td> <td align="center">SHAKE256/256</td>
<td align="right">32</td> <td align="right">32</td>
<td align="right">10</td> <td align="right">10</td>
<td align="center">0x0010</td> <td align="center">0x0010</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M32_H15</td> <td align="left">LMS_SHAKE_M32_H15</td>
<td align="center">SHAKE256/256</td> <td align="center">SHAKE256/256</td>
<td align="right">32</td> <td align="right">32</td>
<td align="right">15</td> <td align="right">15</td>
<td align="center">0x0011</td> <td align="center">0x0011</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M32_H20</td> <td align="left">LMS_SHAKE_M32_H20</td>
<td align="center">SHAKE256/256</td> <td align="center">SHAKE256/256</td>
<td align="right">32</td> <td align="right">32</td>
<td align="right">20</td> <td align="right">20</td>
<td align="center">0x0012</td> <td align="center">0x0012</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M32_H25</td> <td align="left">LMS_SHAKE_M32_H25</td>
<td align="center">SHAKE256/256</td> <td align="center">SHAKE256/256</td>
<td align="right">32</td> <td align="right">32</td>
<td align="right">25</td> <td align="right">25</td>
<td align="center">0x0013</td> <td align="center">0x0013</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M24_H5</td> <td align="left">LMS_SHAKE_M24_H5</td>
<td align="center">SHAKE256/192</td> <td align="center">SHAKE256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">5</td> <td align="right">5</td>
<td align="center">0x0014</td> <td align="center">0x0014</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M24_H10</td> <td align="left">LMS_SHAKE_M24_H10</td>
<td align="center">SHAKE256/192</td> <td align="center">SHAKE256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">10</td> <td align="right">10</td>
<td align="center">0x0015</td> <td align="center">0x0015</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M24_H15</td> <td align="left">LMS_SHAKE_M24_H15</td>
<td align="center">SHAKE256/192</td> <td align="center">SHAKE256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">15</td> <td align="right">15</td>
<td align="center">0x0016</td> <td align="center">0x0016</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M24_H20</td> <td align="left">LMS_SHAKE_M24_H20</td>
<td align="center">SHAKE256/192</td> <td align="center">SHAKE256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">20</td> <td align="right">20</td>
<td align="center">0x0017</td> <td align="center">0x0017</td>
</tr> </tr>
<tr> <tr>
<td align="center">LMS_SHAKE_M24_H25</td> <td align="left">LMS_SHAKE_M24_H25</td>
<td align="center">SHAKE256/192</td> <td align="center">SHAKE256/192</td>
<td align="right">24</td> <td align="right">24</td>
<td align="right">25</td> <td align="right">25</td>
<td align="center">0x0018</td> <td align="center">0x0018</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul empty="true">
<li> Parameter Set Name is the human readable name of the parameter set. </li <dl newline="false" spacing="normal" indent="5">
> <dt>Parameter Set Name:</dt><dd>The human-readable name of the parameter set.<
<li> H is the second-preimage-resistant cryptographic hash function used with /dd>
in this parameter set. </li> <dt>H:</dt><dd>The second-preimage-resistant cryptographic hash function used
<li> m is the the size in bytes of the hash function output. </li> within this parameter set.</dd>
<li> h is the height of the Merkle tree. </li> <dt>m:</dt><dd>The size in bytes of the hash function output.</dd>
<li> id is the IANA-defined identifier used to denote this specific parameter <dt>h:</dt><dd>The height of the Merkle tree.</dd>
set, and which appears in <dt>id:</dt><dd>The IANA-defined identifier used to denote this specific param
both public keys and signatures. </li> eter set, which appears in
</ul> both public keys and signatures.</dd>
</dl>
<t> <t>
These values are additions to the entries in Table 2 of RFC 8554. These values are additions to the entries in Table 2 of <xref target="RFC8554"/> .
</t> </t>
<t> <t>
The SHA256_M24, SHAKE_M32, SHAKE_M24 in the parameter set name denote the The SHA256_M24, SHAKE_M32, and SHAKE_M24 in the parameter set names denote the
SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions defined in <xref targe SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions defined in <xref targ
t="hashfunctions" format="default"/>. et="hashfunctions" format="default"/>.
</t> </t>
</section> </section>
<section anchor="usage_within_lms" numbered="true" toc="default"> <section anchor="usage_within_lms" numbered="true" toc="default">
<name>Usage for these additional hash functions within HSS</name> <name>Usage for These Additional Hash Functions within HSS</name>
<t> <t>
To use the additional hash functions within HSS, one would use the appropriate L MOTS id from <xref target="ldwm_sig_table" format="default"/> and the appropriat e LMS id from <xref target="lms_table" format="default"/>, and use that addition al hash function when computing the hashes for key generation, signature generat ion and signature verification. To use the additional hash functions within HSS, one would use the appropriate L MOTS id from <xref target="ldwm_sig_table" format="default"/> and the appropriat e LMS id from <xref target="lms_table" format="default"/> and use that additiona l hash function when computing the hashes for key generation, signature generati on, and signature verification.
</t> </t>
<t> <t>
Note that the size of the I Merkle tree identifier remains 16 bytes, independent of what hash function is used. Note that the size of the I Merkle tree identifier remains 16 bytes, independent of what hash function is used.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Parameter Set Selection</name> <name>Parameter Set Selection</name>
<t> <t>
This document, along with <xref target="RFC8554" format="default"/>, defines fou This document, along with <xref target="RFC8554" format="default"/>, defines fou
r hash functions for use within HSS/LMS; namely SHA-256, SHA-256/192, SHAKE256/2 r hash functions for use within HSS/LMS: SHA-256, SHA-256/192, SHAKE256/256, and
56 and SHAKE256/192. SHAKE256/192.
The main reason one would select a hash with a 192 bit output (either SHA-256/19 The main reason one would select a hash with a 192-bit output (either SHA-256/19
2 or SHAKE256/192) would be to reduce the signature size; 2 or SHAKE256/192) would be to reduce the signature size;
this comes at the cost of reducing the security margin; however the security sho this comes at the cost of reducing the security margin. However, the security sh
uld be sufficient for most uses. ould be sufficient for most uses.</t>
In contrast, there is no security or signature size difference between the SHA-2 <t>In contrast, there is no security or signature size difference between the SH
56 based parameter sets (SHA-256 or SHA-256/192) versus the A-256-based parameter sets (SHA-256 or SHA-256/192) versus the
SHAKE based parameter sets (SHAKE256/256 or SHAKE256/192); the reason for select SHAKE-based parameter sets (SHAKE256/256 or SHAKE256/192). The reason for select
ing between the two would be based on practical considerations, ing 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 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. two happens to give better hashing performance on the platform.
</t> </t>
</section> </section>
<section anchor="parm_set_comparison" numbered="true" toc="default"> <section anchor="parm_set_comparison" numbered="true" toc="default">
<name>Comparisons of 192 bit and 256 bit parameter sets</name> <name>Comparisons of 192-Bit and 256-Bit Parameter Sets</name>
<t> <t>
Switching to a 192 bit hash affects the signature size, the computation time, an d the security strength. Switching to a 192-bit hash affects the signature size, the computation time, an d 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="de fault"/> for a discussion of 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="de fault"/> for a discussion of the security strength.
</t> </t>
<t> <t>
The impact on signature size and computation time is based on two effects: The impact on signature size and computation time is based on two effects:
</t> </t>
<ol> <ol>
<li> Each hash that appears in the signature is shorter. </li> <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> <li> We need fewer Winternitz chains (because LM-OTS signs a shorter value). </li>
</ol> </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 becaus
e
the signature consists of a series of hashes and each hash is shorter. The se
cond
is relevant because when we need fewer Winternitz chains, we need fewer hashe
s 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> <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 Winter nitz chains, we need fewer hashes in each LM-OTS signature). 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 Winter nitz chains, we need fewer hashes in each LM-OTS signature).
</t> </t>
<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), however effect 2 still applies. For example, with W=8, SHA-256 requires 34 Wint ernitz 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. For computation time (for both signature generation and verification), effect 1 is irrelevant (we still need to perform essentially the same hash computation), but effect 2 still applies. For example, with W=8, SHA-256 requires 34 Winterni tz chains per LM-OTS signature, but SHA-256/192 requires only 26. Since the vas t majority of time (for both signature generation and verification) is spent com puting these Winternitz chains, this reduction in the number of chains gives us some performance improvement.
</t> </t>
<t> <t>
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: Here is a table that gives the space used by both the 256-bit and 192-bit parame ter sets for a range of plausible Winternitz parameters and tree heights:
</t> </t>
<table anchor="measured_performance" align="center"> <table anchor="measured_performance" align="center">
<thead> <thead>
<tr> <tr>
<th align="center">ParmSet</th> <th align="center">ParmSet</th>
<th align="center">Winternitz</th> <th align="center">Winternitz</th>
<th align="center">256 bit hash</th> <th align="center">256-bit hash</th>
<th align="center">192 bit hash</th> <th align="center">192-bit hash</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">15</td> <td align="center">15</td>
<td align="center">4</td> <td align="center">4</td>
<td align="center">2672</td> <td align="center">2672</td>
<td align="center">1624</td> <td align="center">1624</td>
</tr> </tr>
<tr> <tr>
skipping to change at line 567 skipping to change at line 687
<td align="center">3412</td> <td align="center">3412</td>
</tr> </tr>
<tr> <tr>
<td align="center">20/15</td> <td align="center">20/15</td>
<td align="center">8</td> <td align="center">8</td>
<td align="center">3444</td> <td align="center">3444</td>
<td align="center">2212</td> <td align="center">2212</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>ParmSet: this is the height of the Merkle tree(s), which is the paramet
er "h" from <xref target="lms_table" format="default"/>. <dl spacing="normal" newline="false">
Parameter sets listed as <dt>ParmSet:</dt><dd>The height of the Merkle tree(s), which
a single integer have L=1, and consist of a single Merkle tree of that hei is the parameter "h" from <xref target="lms_table" format="default"/>.
ght; Parameter sets listed as a single integer have L=1 and consist of a
parameter sets with L=2 are listed as x/y, with single Merkle tree of that height; parameter sets with L=2 are listed
x being the height of the top level Merkle tree, and y being the as x/y, with x being the height of the top-level Merkle tree and y
bottom level. being the bottom level.</dd>
</t> <dt>Winternitz:</dt><dd>The Winternitz parameter used, which
<t> Winternitz: this is the Winternitz parameter used, which is the param is the parameter "w" from <xref target="ldwm_sig_table"
eter "w" from <xref target="ldwm_sig_table" format="default"/>. For the tests t format="default"/>. For the tests that use multiple trees, this
hat use multiple trees, this applies to all of them. applies to all of them.</dd>
</t> <dt>256-bit hash:</dt><dd>The size in bytes of a signature, assuming
<t> 256 bit hash: the size in bytes of a signature, assuming that a 256 b that a 256-bit hash is used in the signature (either SHA-256 or
it hash is used in the signature (either SHA-256 or SHAKE256/256). SHAKE256/256).</dd>
</t> <dt>192-bit hash:</dt><dd>The size in bytes of a signature, assuming
<t> 192 bit hash: the size in bytes of a signature, assuming that a 192 b that a 192-bit hash is used in the signature (either SHA-256/192 or
it hash is used in the signature (either SHA-256/192 or SHAKE256/192). SHAKE256/192).</dd>
</t> </dl>
<t>An examination of the signature sizes shows that the 192 bit parameters
consistently give <t>An examination of the signature sizes shows that the 192-bit parameters
a 35% - 40% reduction in the size of the signature in comparison with the 256 bi consistently give
t parameters. a 35-40% reduction in the size of the signature in comparison with the 256-bit p
</t> arameters.
<t>For SHA-256/192, there is a smaller (circa 20%) reduction in the amount </t>
of computation required for a signature operation with a 192 bit hash (for reas
on 2 listed above). <!-- [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 reas
on 2 listed above).
The SHAKE256/192 signatures may have either a faster or slower computation, depe nding on the implementation speed of SHAKE versus SHA-256 hashes. The SHAKE256/192 signatures may have either a faster or slower computation, depe nding on the implementation speed of SHAKE versus SHA-256 hashes.
</t> </t>
<t> <t>
The SHAKE256/256 based parameter sets give no space advantage (or disadvantage) over the existing SHA-256-based parameter sets; The SHAKE256/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. any performance delta would depend solely on the implementation and whether they can generate SHAKE hashes faster than SHA-256 ones.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
The strength of a signature that uses the SHA-256/192, SHAKE256/256 and SHAKE256 /192 hash functions is based The strength of a signature that uses the SHA-256/192, SHAKE256/256, and SHAKE25 6/192 hash functions is based
on the difficulty in finding preimages or second preimages to those hash functio ns. on the difficulty in finding preimages or second preimages to those hash functio ns.
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 a nd SHAKE256/192). 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 a nd SHAKE256/192).
That is, the strength of SHA-256/192 and SHAKE256/192 can be expected to be equi valent to the strength of AES-192, while the strength of SHAKE256/256 is equival ent to the strength of AES-256. That is, the strength of SHA-256/192 and SHAKE256/192 can be expected to be equi valent to the strength of AES-192, while the strength of SHAKE256/256 is equival ent to the strength of AES-256.
If AES-192 and AES-256 are Quantum Resistant, so we expect SHA-256/192, SHAKE256 /192 and SHAKE256/256 to be. If AES-192 and AES-256 are quantum-resistant, then we expect SHA-256/192, SHAKE2 56/192, and SHAKE256/256 to also be.
</t> </t>
<t> <t>
If we look at this in a different way, we see that the case of SHAKE256/256 is e ssentially the same as the existing SHA-256 based signatures; the difficultly If we look at this in a different way, we see that the case of SHAKE256/256 is e ssentially the same as the existing SHA-256-based signatures; the difficultly
of finding preimages and second preimages is essentially the same, and so they h ave (barring unexpected cryptographical advances) of finding preimages and second preimages is essentially the same, and so they h ave (barring unexpected cryptographical advances)
essentially the same level of security. essentially the same level of security.
</t> </t>
<t> <t>
The case of SHA-256/192 and SHAKE256/192 requires closer analysis. The case of SHA-256/192 and SHAKE256/192 requires closer analysis.
</t> </t>
<t> <t>
For a classical (nonquantum) computer, there is no known attack better than perf orming hashes For a classical (non-quantum) computer, there is no known attack better than per forming hashes
of a large number of distinct preimages. Therefore, a successful attack has a h igh probability of a large number of distinct preimages. Therefore, a successful attack has a h igh probability
of requiring nearly 2**192 hash computations (for either SHA-256/192 or SHAKE256 of requiring nearly 2<sup>192</sup> hash computations (for either SHA-256/192 or
/192). SHAKE256/192).
These can be taken as the expected work effort, and would appear to be completel These can be taken as the expected work effort and would appear to be completely
y
infeasible in practice. infeasible in practice.
</t> </t>
<!-- [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 Quantum 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> <t>
With a Quantum Computer, an attacker could in theory use Grover's algorithm <xre f target="Grover96" format="default"/> to reduce In theory, an attacker with a quantum computer could use Grover's algorithm <xre f target="Grover96" format="default"/> to reduce
the expected complexity to circa 2**96 hash computations (for N=24). On the oth er the expected complexity to circa 2**96 hash computations (for N=24). On the oth er
hand, implementing Grover's algorithm with this number of hash computations woul d hand, implementing Grover's algorithm with this number of hash computations woul d
require performing circa 2**96 hash computations in succession, which will take require performing circa 2**96 hash computations in succession, which will take
more time than is likely to be acceptable to any attacker. more time than is likely to be acceptable to any attacker.
To speed this up, To speed this up,
the attacker would need to run a number of instances of Grover's algorithm in 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, parallel. This would necessarily increase the total work effort required,
and to an extent that makes it likely to be infeasible. and to an extent, that makes it likely infeasible.
This is because if we limit the time taken by Grover's algorithm to 2**t steps ( This is because if we limit the time taken by Grover's algorithm to 2**t steps (
for t &lt;= 96), then to attack a hash preimage problem of 192 bits, it requires for t &lt;= 96), then to attack a hash preimage problem of 192 bits, it requires
a total of 2**(192-t) hash computations (rather than the 2**(192/2) hash comput a total of 2**(192-t) hash computations, rather than the 2**(192/2) hash comput
ations it would require if we did not limit the time taken). ations it would require if we did not limit the time taken.
In other words, the hash preimage can be found in 2**t steps by using 2**(192-2t In other words, the hash preimage can be found in 2**t steps by using 2**(192-2t
) Quantum Computers (for t &lt;= 96), with one of the Quantum Computers finding ) quantum computers (for t &lt;= 96), with one of the quantum computers finding
the preimage. the preimage.
For example, if the adversary is willing to wait for 2**64 times the time taken 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 by a hash computation (which is over 50 years if a quantum computer can compute
a hash in 0.1 nsec), this implies that a total of 2**(192-64) = 2**128 hash comp a hash in 0.1 nanoseconds), this implies that a total of 2**(192-64) = 2**128 ha
utations will need to be performed, performing the computations on 2**64 (18 qui sh computations will need to be performed, performing the computations on 2**64
ntillion) separate Quantum Computers, each of which computes 2**64 hash evaluati (18 quintillion) separate quantum computers, each of which computes 2**64 hash e
ons. valuations.
</t> </t>
<t> <t>
Hence, we expect that HSS/LMS based on these hash functions is secure against bo th classical and quantum computers, Hence, we expect that HSS/LMS based on these hash functions is secure against bo th 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. 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>
<t> <t>
SHA-256 is subject to a length extension attack. SHA-256 is subject to a length extension attack.
In this attack, if the attacker is given the hash value of an unknown message (a nd the message length) then the attacker can compute the hash of the message app ended with certain strings (even though the attacker does not know the contents of the initial part of the modified message). In this attack, if the attacker is given the hash value of an unknown message (a nd the message length), then the attacker can compute the hash of the message ap pended 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: This would appear to be irrelevant to HSS for two reasons:
</t> </t>
<ul spacing="compact"> <ul>
<li> For the initial message hash, the hash is entirely on public data. Hence th <li> For the initial message hash, the hash is entirely on public data. Hence, t
is attack is irrelevant, because the attacker could compute the hash of the mess his attack is irrelevant, because the attacker could compute the hash of the mes
age with appended data anyways. </li> sage with appended data anyways. </li>
<li> The rest of the hashes within HSS are fixed length, and hence there is no o <li> The rest of the hashes within HSS are fixed length. Hence, there is no oppo
pportunity to perform length extension attacks.</li> rtunity to perform length extension attacks.</li>
</ul> </ul>
<!-- [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> <t>
In addition, to perform a length extension attack on SHA-256/192, the attacker h as 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 S HA256. In addition, to perform a length extension attack on SHA-256/192, the attacker h as 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> </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> <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 signature which is valid for two different messages. 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 signature that is v alid 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. 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 messa ges is feasible only if the signer signed both messages. That is, practically speaking, a signature that is valid for two colliding messa ges 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 pick s the random C value) would have to break the collision resistance of the hash f unction to generate those two colliding messages. For this to happen, a signer (that is, the one with the private key and who pick s the random C value) would have to break the collision resistance of the hash f unction to generate those two colliding messages.
Note that this does not apply to someone who submits the messages for signing, o nly the signer could perform this. Note that this does not apply to someone who submits the messages for signing; o nly 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 f or any message. 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 f or 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 reduce d; 128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192. 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 reduce d; 128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192.
</t> </t>
<t> <t>
Some cryptographers have raised the possibility of a multitarget attack (where t he attacker has signatures from a large number of public keys, and succeeds if h e can generate a forgery against any one of those public keys). Some cryptographers have raised the possibility of a multi-target attack (where the attacker has signatures from a large number of public keys and succeeds if t hey can generate a forgery against any one of those public keys).
While no such method of attack has been proposed, the possibility cannot be excl uded; if there are a large number of public keys, it might be prudent to conside r the possibility of some security loss with N=24. While no such method of attack has been proposed, the possibility cannot be excl uded; if there are a large number of public keys, it might be prudent to conside r 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. If there are 2**K public keys, this security loss cannot be more than K bits of security.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Note on the version of SHAKE</name> <name>Note on the Version of SHAKE</name>
<t> <t>
<xref target="FIPS202" format="default"/> defines both SHAKE128 and SHAKE256. T
FIPS 202 <xref target="FIPS202" format="default"/> defines both SHAKE128 and SHA his specification selects SHAKE256, even though it is less efficient
KE256. This specification selects SHAKE256, even though it is, for large messages. The reason is that SHAKE128 has a low upper bound on the di
for large messages, less efficient. The reason is that SHAKE128 has a low upper fficulty
bound on the difficulty
of finding preimages (due to the invertibility of its internal permutation), whi ch would limit the strength of finding preimages (due to the invertibility of its internal permutation), whi ch would limit the strength
of HSS/LMS (whose strength is based on the difficulty of finding preimages). He nce, we specify the use of of HSS/LMS (whose strength is based on the difficulty of finding preimages). He nce, we specify the use of
SHAKE256, which has a considerably stronger preimage resistance. SHAKE256, which has a considerably stronger preimage resistance.
</t> </t>
</section> </section>
</section> </section>
<section> <section>
<name>IANA considerations</name> <name>IANA Considerations</name>
<t>
IANA has assigned the code points for all the additional parameter sets in Secti <!-- [rfced] Questions about IANA values
on 3 (in the IANA "LM-OTS Signatures" registry) and in Section 4 (in the IANA "L
eighton-Micali Signatures (LMS)" registry). These assignments are also included a) Should the values in the "id" column in Tables 1 and 2 be updated to
in NIST SP 800-208, but the IANA registrations refer to this document alone. exactly match the values in the "Numeric Identifier" column of the "LM-OTS
</t> Signatures" and "Leighton-Micali Signatures (LMS)" registries in regard to
</section> capitalization and leading zeroes? We understand that these hex values are the
<section> same.
<name>Acknowledgements</name>
Examples:
"id" column of Table 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-sign
atures.xhtml#leighton-micali-signatures-1
https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-sign
atures.xhtml#lm-ots-signatures
b) Some of these values also appear in Appendix A but without the "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 the names below should be updated as follows to
align with the parameter set names in Tables 1 and 2 (and in the IANA
registries). Please confirm. Note that there are two instances of of each in
the document.
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> <t>
We would like to thank Carsten Bormann, Russ Housley, Andrey Jivsov, Mallory Kno del, Virendra Kumar, Thomas Pornin and Stanislav Smyshlyaev for their insightful and helpful reviews. IANA has assigned the code points for the parameter sets in <xref target="ldwm" /> in the "LM-OTS Signatures" registry and the parameter sets in <xref target="m erkle"/> in the "Leighton-Micali Signatures (LMS)" registry. These assignments a re included in <xref target="NIST_SP_800-208"/>, but the IANA registrations only reference this document.
</t> </t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<!-- [rfced] The following reference entries appeared in the Normative
References section but were not cited in the text. We have removed them;
however, if they should be cited in the text, please let us know where to
include them.
[RFC2119]
[RFC3979]
[RFC4879]
[RFC5226]
[RFC8174]
-->
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!--
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 119.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="S. Bradner" initials="S" surname="Bradner"/> 979.xml"/>
<date month="March" year="1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<abstract> 879.xml"/>
<t>In many standards track documents several words are used to sig <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
nify the requirements in the specification. These words are often capitalized. 226.xml"/>
This document defines these words as they should be interpreted in IETF documen <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ts. This document specifies an Internet Best Current Practices for the Internet 174.xml"/>
Community, and requests discussion and suggestions for improvements.</t> -->
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</front> 554.xml"/>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/> <reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.
<seriesInfo name="DOI" value="10.17487/RFC2119"/> FIPS.180-4.pdf">
</reference> <front>
<reference anchor="RFC3979" target="https://www.rfc-editor.org/info/rfc3 <title>Secure Hash Standard</title>
979" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3979.xml"> <author>
<front> <organization abbrev="NIST">National Institute of Standards and Technology
<title>Intellectual Property Rights in IETF Technology</title> </organization>
<author fullname="S. Bradner" initials="S" role="editor" surname="Br </author>
adner"/> <date month="August" year="2015"/>
<date month="March" year="2005"/> </front>
<abstract> <seriesInfo name="NIST FIPS" value="180-4"/>
<t>The IETF policies about Intellectual Property Rights (IPR), suc <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
h as patent rights, relative to technologies developed in the IETF are designed </reference>
to ensure that IETF working groups and participants have as much information abo
ut any IPR constraints on a technical proposal as possible. The policies are al <reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.
so intended to benefit the Internet community and the public at large, while res FIPS.202.pdf">
pecting the legitimate rights of IPR holders. This memo details the IETF polici <front>
es concerning IPR related to technology worked on within the IETF. It also desc <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Function
ribes the objectives that the policies are designed to meet. This memo updates s</title>
RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also up <author>
dates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including refere <organization abbrev="NIST">National Institute of Standards and Technology
nce [2] in RFC 2418. This document specifies an Internet Best Current Practices </organization>
for the Internet Community, and requests discussion and suggestions for improve </author>
ments.</t> <date month="August" year="2015"/>
</abstract> </front>
</front> <seriesInfo name="NIST FIPS" value="202"/>
<seriesInfo name="RFC" value="3979"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
<seriesInfo name="DOI" value="10.17487/RFC3979"/> </reference>
</reference>
<reference anchor="RFC4879" target="https://www.rfc-editor.org/info/rfc4
879" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4879.xml">
<front>
<title>Clarification of the Third Party Disclosure Procedure in RFC
3979</title>
<author fullname="T. Narten" initials="T" surname="Narten"/>
<date month="April" year="2007"/>
<abstract>
<t>This document clarifies and updates a single sentence in RFC 39
79. Specifically, when third party Intellectual Property Rights (IPR) disclosur
es are made, the intention is that the IETF Executive Director notify the IPR ho
lder that a third party disclosure has been filed, and to ask the IPR holder whe
ther they have any disclosure that needs to be made, per applicable RFC 3979 rul
es. 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/rfc5
226" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<front>
<title>Guidelines for Writing an IANA Considerations 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 use of identifiers consisting of constants
and other well-known values. Even after a protocol has been defined and deployme
nt has begun, new values may need to be assigned (e.g., for a new option type in
DHCP, or a new encryption or authentication transform for IPsec). To ensure tha
t such quantities have consistent values and interpretations across all implemen
tations, their assignment must be administered by a central authority. For IETF
protocols, that role is provided by the Internet Assigned Numbers Authority (IAN
A).</t>
<t>In order for IANA to manage a given namespace prudently, it nee
ds guidelines describing the conditions under which new values can be assigned o
r when modifications to existing values can be made. If IANA is expected to play
a role in the management of a namespace, IANA must be given clear and concise i
nstructions describing that role. This document discusses issues that should be
considered in formulating a policy for assigning values to a namespace and provi
des guidelines for authors on the specific text that must be included in documen
ts that place demands on IANA.</t>
<t>This document obsoletes RFC 2434. This document specifies an In
ternet Best Current Practices for the Internet Community, and requests discussio
n and suggestions 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/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 in protoco
l
specifications. This document aims to reduce the ambiguity 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/rfc8
554" 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 cryptog
raphic hash functions, following the seminal work in this area of Lamport, Diffi
e, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifi
es a one-time signature scheme and a general signature scheme. These systems pro
vide asymmetric authentication without using large integer mathematics and can a
chieve a high security level. They are suitable for compact implementations, are
relatively simple to implement, and are naturally resistant to side-channel att
acks. 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 of the Crypto Forum Research Group (
CFRG) in the IRTF. This has been reviewed by many researchers, both in the resea
rch 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>
<reference anchor="FIPS180">
<front>
<title>Secure Hash Standard (SHS)</title>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date month="March" year="2012"/>
</front>
<seriesInfo name="FIPS" value="180-4"/>
</reference>
<reference anchor="FIPS202">
<front>
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output
Functions</title>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date month="August" year="2015"/>
</front>
<seriesInfo name="FIPS" value="202"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <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"> <reference anchor="Grover96">
<front> <front>
<title>A fast quantum mechanical algorithm for database search</titl e> <title>A fast quantum mechanical algorithm for database search</titl e>
<author surname="Grover" initials="L.K."> <author surname="Grover" initials="L.">
<organization/> <organization/>
</author> </author>
<date year="1996"/> <date month="July" year="1996"/>
</front> </front>
<seriesInfo name="28th ACM Symposium on the Theory of Computing" value <refcontent>Proceedings of the twenty-eighth annual ACM symposium on T
="p. 212"/> heory of Computing (STOC '96), pp. 212-219</refcontent>
<seriesInfo name="DOI" value="10.1145/237814.237866"/>
</reference> </reference>
<reference anchor="Katz16"> <reference anchor="Katz16">
<front> <front>
<title>Analysis of a Proposed Hash-Based Signature Standard</title> <title>Analysis of a Proposed Hash-Based Signature Standard</title>
<author surname="Katz" initials="J."> <author surname="Katz" initials="J.">
<organization/> <organization/>
</author> </author>
<date year="2016"/> <date year="2016"/>
</front> </front>
<seriesInfo name="SSR 2016: Security Standardisation Research" value=" pp. 261-273"/> <refcontent>Security Standardisation Research (SSR 2016), Lecture Note s in Computer Science, vol. 10074, pp. 261-273</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-319-49100-4_12"/> <seriesInfo name="DOI" value="10.1007/978-3-319-49100-4_12"/>
</reference> </reference>
<reference anchor="NIST_SP_800-208"> <reference anchor="NIST_SP_800-208">
<front> <front>
<title>Recommendation for Stateful Hash-Based Signature Schemes</tit le> <title>Recommendation for Stateful Hash-Based Signature Schemes</tit le>
<author> <author fullname="David A. Cooper" surname="Cooper" initials="D."/>
<organization>National Institute of Standards and Technology</orga <author fullname="Daniel C. Apon" surname="Apon" initials="D."/>
nization> <author fullname="Quynh H. Dang" surname="Dang" initials="Q."/>
</author> <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"/> <date month="October" year="2020"/>
</front> </front>
<refcontent>National Institute of Standards and Technology</refcontent >
<seriesInfo name="NIST SP" value="800-208"/> <seriesInfo name="NIST SP" value="800-208"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-208"/>
</reference> </reference>
</references> </references>
</references> </references>
<!-- [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"> <section numbered="true" toc="default">
<name>Test Cases</name> <name>Test Cases</name>
<t> <t>
This section provides three test cases that can be used to verify or debug This appendix provides four test cases that can be used to verify or
an implementation, one for each hash function. debug an implementation.
This data is formatted with the name of the This data is formatted with the name of the
elements on the left, and the value of the elements on the right, in elements on the left and the value of the elements on the right, in
hexadecimal. The concatenation of all of the values within a public hexadecimal. The concatenation of all of the values within a public
key or signature produces that public key or signature, and values key or signature produces that public key or signature, and values
that do not fit within a single line are listed across successive that do not fit within a single line are listed across successive
lines. lines.
</t> </t>
<t keepWithNext="true">Test Case 1 Private Key for SHA-256/192</t>
<figure>
<name>Test Case 1 - Private Key for SHA-256/192</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
(note: procedure in Appendix A of [RFC8554] is used) (note: procedure in Appendix A of [RFC8554] is used)
SEED 000102030405060708090a0b0c0d0e0f SEED 000102030405060708090a0b0c0d0e0f
1011121314151617 1011121314151617
I 202122232425262728292a2b2c2d2e2f I 202122232425262728292a2b2c2d2e2f
-------------------------------------------- --------------------------------------------
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 1 Public Key for SHA-256/192</t> </figure>
<figure>
<name>Test Case 1 - Public Key for SHA-256/192</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
HSS public key HSS public key
levels 00000001 levels 00000001
-------------------------------------------- --------------------------------------------
LMS type 0000000a # LMS_SHA256_M24_H5 LMS type 0000000a # LMS_SHA256_M24_H5
LMOTS type 00000008 # LMOTS_SHA256_N24_W8 LMOTS type 00000008 # LMOTS_SHA256_N24_W8
I 202122232425262728292a2b2c2d2e2f I 202122232425262728292a2b2c2d2e2f
K 2c571450aed99cfb4f4ac285da148827 K 2c571450aed99cfb4f4ac285da148827
96618314508b12d2 96618314508b12d2
-------------------------------------------- --------------------------------------------
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 1 Message for SHA-256/192</t> </figure>
<figure>
<name>Test Case 1 - Message for SHA-256/192</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
Message 54657374206d65737361676520666f72 |Test message for| Message 54657374206d65737361676520666f72 |Test message for|
205348413235362d3139320a | SHA-256/192.| 205348413235362d3139320a | SHA-256/192.|
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 1 Signature for SHA-256/192</t> </figure>
<figure>
<name>Test Case 1 - Signature for SHA-256/192</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
HSS signature HSS signature
Nspk 00000000 Nspk 00000000
sig[0]: sig[0]:
-------------------------------------------- --------------------------------------------
LMS signature LMS signature
q 00000005 q 00000005
-------------------------------------------- --------------------------------------------
LMOTS signature LMOTS signature
skipping to change at line 950 skipping to change at line 1213
4ea64209942fbae3 4ea64209942fbae3
path[1] 38d19f152182c807d3c40b189d3fcbea path[1] 38d19f152182c807d3c40b189d3fcbea
942f44682439b191 942f44682439b191
path[2] 332d33ae0b761a2a8f984b56b2ac2fd4 path[2] 332d33ae0b761a2a8f984b56b2ac2fd4
ab08223a69ed1f77 ab08223a69ed1f77
path[3] 19c7aa7e9eee96504b0e60c6bb5c942d path[3] 19c7aa7e9eee96504b0e60c6bb5c942d
695f0493eb25f80a 695f0493eb25f80a
path[4] 5871cffd131d0e04ffe5065bc7875e82 path[4] 5871cffd131d0e04ffe5065bc7875e82
d34b40b69dd9f3c1 d34b40b69dd9f3c1
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 2 Private Key for SHAKE256/192</t> </figure>
<figure>
<name>Test Case 2 - Private Key for SHAKE256/192</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
(note: procedure in Appendix A of [RFC8554] is used) (note: procedure in Appendix A of [RFC8554] is used)
SEED 303132333435363738393a3b3c3d3e3f SEED 303132333435363738393a3b3c3d3e3f
4041424344454647 4041424344454647
I 505152535455565758595a5b5c5d5e5f I 505152535455565758595a5b5c5d5e5f
-------------------------------------------- --------------------------------------------
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 2 Public Key for SHAKE256/192</t> </figure>
<figure>
<name>Test Case 2 - Public Key for SHAKE256/192</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
--------------------------------------------- ---------------------------------------------
HSS public key HSS public key
levels 00000001 levels 00000001
-------------------------------------------- --------------------------------------------
LMS type 00000014 # LMS_SHAKE256_N24_H5 LMS type 00000014 # LMS_SHAKE256_N24_H5
LMOTS type 00000010 # LMOTS_SHAKE256_N24_W8 LMOTS type 00000010 # LMOTS_SHAKE256_N24_W8
I 505152535455565758595a5b5c5d5e5f I 505152535455565758595a5b5c5d5e5f
K db54a4509901051c01e26d9990e55034 K db54a4509901051c01e26d9990e55034
7986da87924ff0b1 7986da87924ff0b1
-------------------------------------------- --------------------------------------------
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 2 Message for SHAKE256/192</t> </figure>
<figure>
<name>Test Case 2 - Message for SHAKE256/192</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
Message 54657374206d65737361676520666f72 |Test message for| Message 54657374206d65737361676520666f72 |Test message for|
205348414b453235362d3139320a | SHAKE256/192.| 205348414b453235362d3139320a | SHAKE256/192.|
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 2 Signature for SHAKE256/192</t> </figure>
<figure>
<name>Test Case 2 - Signature for SHAKE256/192</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
HSS signature HSS signature
Nspk 00000000 Nspk 00000000
sig[0]: sig[0]:
-------------------------------------------- --------------------------------------------
LMS signature LMS signature
q 00000006 q 00000006
-------------------------------------------- --------------------------------------------
LMOTS signature LMOTS signature
skipping to change at line 1060 skipping to change at line 1331
a7fb05d995b5721a a7fb05d995b5721a
path[1] 27096a5007d82f79d063acd434a04e97 path[1] 27096a5007d82f79d063acd434a04e97
f61552f7f81a9317 f61552f7f81a9317
path[2] b4ec7c87a5ed10c881928fc6ebce6dfc path[2] b4ec7c87a5ed10c881928fc6ebce6dfc
e9daae9cc9dba690 e9daae9cc9dba690
path[3] 7ca9a9dd5f9f573704d5e6cf22a43b04 path[3] 7ca9a9dd5f9f573704d5e6cf22a43b04
e64c1ffc7e1c442e e64c1ffc7e1c442e
path[4] cb495ba265f465c56291a902e62a461f path[4] cb495ba265f465c56291a902e62a461f
6dfda232457fad14 6dfda232457fad14
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 3 Private Key for SHAKE256/256</t> </figure>
<figure>
<name>Test Case 3 - Private Key for SHAKE256/256</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
(note: procedure in Appendix A of [RFC8554] is used) (note: procedure in Appendix A of [RFC8554] is used)
SEED 606162636465666768696a6b6c6d6e6f SEED 606162636465666768696a6b6c6d6e6f
707172737475767778797a7b7c7d7e7f 707172737475767778797a7b7c7d7e7f
I 808182838485868788898a8b8c8d8e8f I 808182838485868788898a8b8c8d8e8f
-------------------------------------------- --------------------------------------------
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 3 Public Key for SHAKE256/256</t> </figure>
<figure>
<name>Test Case 3 - Public Key for SHAKE256/256</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
HSS public key HSS public key
levels 00000001 levels 00000001
-------------------------------------------- --------------------------------------------
LMS type 0000000f # LMS_SHAKE256_N32_H5 LMS type 0000000f # LMS_SHAKE256_N32_H5
LMOTS type 0000000c # LMOTS_SHAKE256_N32_W8 LMOTS type 0000000c # LMOTS_SHAKE256_N32_W8
I 808182838485868788898a8b8c8d8e8f I 808182838485868788898a8b8c8d8e8f
K 9bb7faee411cae806c16a466c3191a8b K 9bb7faee411cae806c16a466c3191a8b
65d0ac31932bbf0c2d07c7a4a36379fe 65d0ac31932bbf0c2d07c7a4a36379fe
-------------------------------------------- --------------------------------------------
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 3 Message for SHAKE256/256</t> </figure>
<figure>
<name>Test Case 3 - Message for SHAKE256/256</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
Message 54657374206d657361676520666f7220 |Test mesage for | Message 54657374206d657361676520666f7220 |Test message for|
5348414b453235362d3235360a |SHAKE256/256.| 5348414b453235362d3235360a |SHAKE256/256.|
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 3 Signature for SHAKE256/256</t> </figure>
<figure>
<name>Test Case 3 - Signature for SHAKE256/256</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
HSS signature HSS signature
Nspk 00000000 Nspk 00000000
sig[0]: sig[0]:
-------------------------------------------- --------------------------------------------
LMS signature LMS signature
q 00000007 q 00000007
-------------------------------------------- --------------------------------------------
LMOTS signature LMOTS signature
skipping to change at line 1186 skipping to change at line 1465
5d65b242b714bc5a756ba5e228abfa0d 5d65b242b714bc5a756ba5e228abfa0d
path[1] 1329978a05d5e815cf4d74c1e547ec4a path[1] 1329978a05d5e815cf4d74c1e547ec4a
a3ca956ae927df8b29fb9fab3917a7a4 a3ca956ae927df8b29fb9fab3917a7a4
path[2] ae61ba57e5342e9db12caf6f6dbc5253 path[2] ae61ba57e5342e9db12caf6f6dbc5253
de5268d4b0c4ce4ebe6852f012b162fc de5268d4b0c4ce4ebe6852f012b162fc
path[3] 1c12b9ffc3bcb1d3ac8589777655e22c path[3] 1c12b9ffc3bcb1d3ac8589777655e22c
d9b99ff1e4346fd0efeaa1da044692e7 d9b99ff1e4346fd0efeaa1da044692e7
path[4] ad6bfc337db69849e54411df8920c228 path[4] ad6bfc337db69849e54411df8920c228
a2b7762c11e4b1c49efb74486d3931ea a2b7762c11e4b1c49efb74486d3931ea
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 4 Private Key for for SHA256/192 with W=4 </figure>
</t> <figure>
<name>Test Case 4 - Private Key for SHA256/192 with W=4</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
(note: procedure in Appendix A of [RFC8554] is used) (note: procedure in Appendix A of [RFC8554] is used)
SEED 202122232425262728292a2b2c2d2e2f SEED 202122232425262728292a2b2c2d2e2f
3031323334353637 3031323334353637
I 404142434445464748494a4b4c4d4e4f I 404142434445464748494a4b4c4d4e4f
-------------------------------------------- --------------------------------------------
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 4 Public Key for for SHA256/192 with W=4< </figure>
/t> <figure>
<name>Test Case 4 - Public Key for SHA256/192 with W=4</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
HSS public key HSS public key
levels 00000001 levels 00000001
-------------------------------------------- --------------------------------------------
LMS type 0000000d # LMS_SHA256_M24_H20 LMS type 0000000d # LMS_SHA256_M24_H20
LMOTS type 00000007 # LMOTS_SHA256_N24_W4 LMOTS type 00000007 # LMOTS_SHA256_N24_W4
I 404142434445464748494a4b4c4d4e4f I 404142434445464748494a4b4c4d4e4f
K 9c08a50d170406869892802ee4142fcd K 9c08a50d170406869892802ee4142fcd
eac990f110c2460c eac990f110c2460c
-------------------------------------------- --------------------------------------------
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 4 Message for for SHA256/192 with W=4</t> </figure>
<figure>
<name>Test Case 4 - Message for SHA256/192 with W=4</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
Message 54657374206d65737361676520666f72 |Test message for| Message 54657374206d65737361676520666f72 |Test message for|
205348413235362f31393220773d34 | SHA256/192 w=4| 205348413235362f31393220773d34 | SHA256/192 w=4|
-------------------------------------------- --------------------------------------------
]]></artwork> ]]></artwork>
<t keepWithNext="true">Test Case 4 Signature for SHA256/192 with W=4</t> </figure>
<figure>
<name>Test Case 4 - Signature for SHA256/192 with W=4</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
-------------------------------------------- --------------------------------------------
HSS signature HSS signature
Nspk 00000000 Nspk 00000000
sig[0]: sig[0]:
-------------------------------------------- --------------------------------------------
LMS signature LMS signature
q 00000064 q 00000064
-------------------------------------------- --------------------------------------------
LMOTS signature LMOTS signature
skipping to change at line 1376 skipping to change at line 1663
071e572fd032c780 071e572fd032c780
path[16] f44c9503a4c03c37417dc96422ba0849 path[16] f44c9503a4c03c37417dc96422ba0849
c37956f9fd5d33ea c37956f9fd5d33ea
path[17] 4fcab84276effec652ca77d7d47ac93c path[17] 4fcab84276effec652ca77d7d47ac93c
633d99e0a236f03d 633d99e0a236f03d
path[18] 5587d1990ffaef737fced1f5cdd8f373 path[18] 5587d1990ffaef737fced1f5cdd8f373
844e9f316aad41a0 844e9f316aad41a0
path[19] b12302639f83a2d74c9fe30d305a942b path[19] b12302639f83a2d74c9fe30d305a942b
c0c30352a5e44dfb c0c30352a5e44dfb
]]></artwork> ]]></artwork>
</figure>
</section> </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> </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> </rfc>
 End of changes. 121 change blocks. 
429 lines changed or deleted 786 lines changed or added

This html diff was produced by rfcdiff 1.48.