]>
Additional Parameter sets for HSS/LMS Hash-Based Signatures
Cisco Systems
170 West Tasman Drive
San Jose
CA
USA
sfluhrer@cisco.com
NIST
100 Bureau Drive
Gaithersburg
MD
USA
quynh.dang@nist.gov
IRTF
Crypto Forum Research Group
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.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
Introduction
Stateful hash based signatures have small private and public keys,
are efficient to compute, and are believed to have excellent security.
One disadvantage is that the signatures they produce tend to be somewhat
large (possibly 1k - 4kbytes).
What this draft explores are a set of parameter sets to the HSS/LMS (RFC8554)
xxmlstateful 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).
This document is intended to be compatible with the NIST document .
Quick note about the distinction between HSS and LMS.
LMS is a stateful hash based signature scheme that a based on a single level Merkle tree.
HSS is a way of binding several LMS signatures together in a hierarchical manner, to increase the number of signatures available.
Strictly speaking, all the signatures that this document discusses are HSS signatures (even if the HSS signature consists of a single LMS signature).
However, it is common to refer to these signatures are LMS signatures.
This document uses the term HSS/LMS to cover both the pedantic and the common meanings.
Disclaimer
This document is not intended as legal advice. Readers are advised to consult with
their own legal advisers if they would like a legal interpretation of their rights.
The IETF policies and processes regarding intellectual property and
patents are outlined in and
and at
https://datatracker.ietf.org/ipr/about.
Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in .
Additional Hash Function Definitions
192 bit Hash Function based on SHA-256
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 .
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.
This is the procedure found in FIPS 180-4 (section 7) for truncating the hash output to 192 bits.
The following test vector may illustrate this:
We use the same IV as the untruncated SHA-256, rather than defining a distinct one,
so that we can use a standard SHA-256 hash implementation without modification.
In addition, the fact that you get partial knowledge of the SHA-256 hash
of a message by examining the SHA-256/192 hash of the same message is
not a concern for this application.
Each message that is hashed is randomized. Any message being signed includes
the C randomizer (a value that is selected by the signer and is included in the hash)
which varies per message.
Therefore, signing the same message by SHA-256 and by SHA-256/192 will not
result in the same value being hashed, and so the latter hash value is not a prefix of the former one.
In addition, all hashes include the I identifier, which is included as a part of the signature process.
This I identifier is selected randomly for each private key (and hence two keys will have different I values with high probability), and
so two intermediate hashes computed as a part of signing with two HSS private keys (one with a SHA-256 parameter set and one a SHA-256/192 parameter set) will also be distinct with high probability.
256 bit Hash Function based on SHAKE256
This document defines a SHAKE-based hash function with a 256 bit output.
As such, we define SHAKE256/256 as a hash where you submit the preimage
to the SHAKE256 XOF, with the output being 256 bits, see FIPS 202 for more detail.
192 bit Hash Function based on SHAKE256
This document defines a SHAKE-based hash function with a 192 bit output.
As such, we define SHAKE256/192 as a hash where you submit the preimage
to the SHAKE256 XOF, with the output being 192 bits, see FIPS 202 for more detail.
Additional LM-OTS Parameter Sets
Here is a table with the LM-OTS parameters defined that use the above hashes:
Parameter Set Name |
H |
n |
w |
p |
ls |
id |

LMOTS_SHA256_N24_W1 |
SHA-256/192 |
24 |
1 |
200 |
8 |
0x0005 |

LMOTS_SHA256_N24_W2 |
SHA-256/192 |
24 |
2 |
101 |
6 |
0x0006 |

LMOTS_SHA256_N24_W4 |
SHA-256/192 |
24 |
4 |
51 |
4 |
0x0007 |

LMOTS_SHA256_N24_W8 |
SHA-256/192 |
24 |
8 |
26 |
0 |
0x0008 |

LMOTS_SHAKE_N32_W1 |
SHAKE256/256 |
32 |
1 |
265 |
7 |
0x0009 |

LMOTS_SHAKE_N32_W2 |
SHAKE256/256 |
32 |
2 |
133 |
6 |
0x000a |

LMOTS_SHAKE_N32_W4 |
SHAKE256/256 |
32 |
4 |
67 |
4 |
0x000b |

LMOTS_SHAKE_N32_W8 |
SHAKE256/256 |
32 |
8 |
34 |
0 |
0x000c |

LMOTS_SHAKE_N24_W1 |
SHAKE256/192 |
24 |
1 |
200 |
8 |
0x000d |

LMOTS_SHAKE_N24_W2 |
SHAKE256/192 |
24 |
2 |
101 |
6 |
0x000e |

LMOTS_SHAKE_N24_W4 |
SHAKE256/192 |
24 |
4 |
51 |
4 |
0x000f |

LMOTS_SHAKE_N24_W8 |
SHAKE256/192 |
24 |
8 |
26 |
0 |
0x0010 |

The id is the IANA-defined identifier used to denote this specific parameter set, and which appears in
both public keys and signatures.
The SHA256_N24, SHAKE_N32, SHAKE_N24 in the parameter set name denote the
SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions defined in .
Remember that the C message randomizer (which is included in the signature) has the same size (n bytes) as the hash output,
and so it shrinks from 32 bytes to 24 bytes for the parameter sets that use either SHA-256/192 or SHAKE256/192.
Additional LM Parameter Sets
Here is a table with the LM parameters defined that use SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions:
Parameter Set Name |
H |
m |
h |
id |

LMS_SHA256_M24_H5 |
SHA-256/192 |
24 |
5 |
0x000a |

LMS_SHA256_M24_H10 |
SHA-256/192 |
24 |
10 |
0x000b |

LMS_SHA256_M24_H15 |
SHA-256/192 |
24 |
15 |
0x000c |

LMS_SHA256_M24_H20 |
SHA-256/192 |
24 |
20 |
0x000d |

LMS_SHA256_M24_H25 |
SHA-256/192 |
24 |
25 |
0x000e |

LMS_SHAKE_M32_H5 |
SHAKE256/256 |
32 |
5 |
0x000f |

LMS_SHAKE_M32_H10 |
SHAKE256/256 |
32 |
10 |
0x0010 |

LMS_SHAKE_M32_H15 |
SHAKE256/256 |
32 |
15 |
0x0011 |

LMS_SHAKE_M32_H20 |
SHAKE256/256 |
32 |
20 |
0x0012 |

LMS_SHAKE_M32_H25 |
SHAKE256/256 |
32 |
25 |
0x0013 |

LMS_SHAKE_M24_H5 |
SHAKE256/192 |
24 |
5 |
0x0014 |

LMS_SHAKE_M24_H10 |
SHAKE256/192 |
24 |
10 |
0x0015 |

LMS_SHAKE_M24_H15 |
SHAKE256/192 |
24 |
15 |
0x0016 |

LMS_SHAKE_M24_H20 |
SHAKE256/192 |
24 |
20 |
0x0017 |

LMS_SHAKE_M24_H25 |
SHAKE256/192 |
24 |
25 |
0x0018 |

The id is the IANA-defined identifier used to denote this specific parameter set, and which appears in
both public keys and signatures.
The SHA256_M24, SHAKE_M32, SHAKE_M24 in the parameter set name denote the
SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions defined in .
Usage for these additional hash functions within HSS
To use the additional hash functions within HSS, you would use the appropriate LMOTS id from and the appropriate LMS id from , and use that additional hash function when computing the hashes for key generation, signature generation and signature verification.
Note that the size of the I Merkle tree identifier remains 16 bytes, independent of what hash function is used.
Comparisons of 192 bit and 256 bit parameter sets
Switching to a 192 bit hash affects the signature size, the computation time, and the security strength.
It significantly reduces the signature size and somewhat reduces the computation time, at the cost of security strength. See for a discussion of the security strength.
The impact on signature size and computation time is based on two effects:
- Each hash that appears in the signature is shorter.
- We need fewer Winternitz chains (because LM-OTS signs a shorter value).

For signature length, both effects are relevent (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.
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 Winternitz chains per LM-OTS signature, but SHA-256/192 requires only 26. Since the vast majority of time (for both signature generation and verification) is spent computing these Winternitz chains, this reduction in the number of chains gives us some performance improvement.
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:
ParmSet |
Winternitz |
256 bit hash |
192 bit hash |

15 |
4 |
2672 |
1624 |

15 |
8 |
1616 |
1024 |

20 |
4 |
2832 |
1744 |

20 |
8 |
1776 |
1144 |

15/10 |
4 |
5236 |
3172 |

15/10 |
8 |
3124 |
1972 |

15/15 |
4 |
5396 |
3292 |

15/15 |
8 |
3284 |
2092 |

20/10 |
4 |
5396 |
3292 |

20/10 |
8 |
3284 |
2092 |

20/15 |
4 |
5556 |
3412 |

20/15 |
8 |
3444 |
2212 |

ParmSet: this is the height of the Merkle tree(s), which is the parameter "h" from .
Parameter sets listed as
a single integer have L=1, and consist of a single Merkle tree of that height;
parameter sets with L=2 are listed as x/y, with
x being the height of the top level Merkle tree, and y being the
bottom level.
Winternitz: this is the Winternitz parameter used, with is the parameter "w" from . For the tests that use multiple trees, this applies to all of them.
256 bit hash: the size in bytes of a signature, assuming that a 256 bit hash is used in the signature (either SHA-256 or SHAKE256/256).
192 bit hash: the size in bytes of a signature, assuming that a 192 bit hash is used in the signature (either SHA-256/192 or SHAKE256/192).
An examination of the signature sizes show that the 192 bit parameters consistently give
a 35% - 40% reduction in the size of the signature in comparison with the 256 bit parameters.
For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192 bit hash (for reason 2 listed above).
The SHAKE256/192 signatures may have either a faster or slower computation, depending on the implementation speed of SHAKE versus SHA-256 hashes.
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.
Parameter Set Selection
This document, along with , defines four hash functions for use within HSS/LMS; namely SHA-256, SHA-256/192, SHAKE256/256 and SHAKE256/192.
The main reason one would select a hash with a 192 bit output (either SHA-256/192 or SHAKE256/192) would be to reduce the signature size;
this does this at the cost of reducing the security margin; however the security should be sufficient for most uses.
In contrast, there is no security or signature size difference between the SHA-256 based parameter sets (SHA-256 or SHA-256/192) versus the
SHAKE based parameter sets (SHAKE256/256 or SHAKE256/192); the reason for selecting between the two would be based on practical considerations,
for example, if your implementation happens to have an existing SHA-256 (or SHAKE) implementation already present or if one of the
two happens to give better hashing performance on your platform.
Security Considerations
The strength of a signature that uses the SHA-256/192, SHAKE256/256 and SHAKE256/192 hash functions is based
on the difficulty in finding preimages or second preimages to those hash functions.
As shown in , 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-2/192 and SHAKE256/192).
That is, the strength of SHA-256/192 and SHAKE256/192 can be expected to be equivalent to the strength of AES-192, while the strength of SHAKE256/256 is equivalent to the strength of AES-256.
If AES-192 and AES-256 are Quantum Resistant, so we expect SHA-256/192, SHAKE256/192 and SHAKE256/256 to be.
If we look at this in a different way, we see that the case of SHAKE256/256 is essentially the same as the existing SHA-256 based signatures; the difficultly
of finding preimages and second preimages is essentially the same, and so they have (barring unexpected cryptographical advances)
essentially the same level of security.
The case of SHA-256/192 and SHAKE256/192 requires closer analysis.
For a classical (nonquantum) computer, there is no known attack better than performing hashes
of a large number of distinct preimages. Therefore, a successful attack has a high probability
of requiring nearly 2**192 hash computations (for either SHA-256/192 or SHAKE256/192).
These can be taken as the expected work effort, and would appear to be completely
infeasible in practice.
With a Quantum Computer, an attacker could in theory use Grover's algorithm to reduce
the expected complexity required to circa 2**96 hash computations (for N=24). On the other
hand, implementing Grover's algorithm with this number of hash computations would
require performing circa 2**96 hash computations in succession, which will take
more time than is likely to be acceptable to any attacker.
To speed this up,
the attacker would need to run a number of instances of Grover's algorithm in
parallel. This would necessarily increase the total work effort required,
and to an extent that makes it likely to be infeasible.
This is because if we limit the time taken by Grover's algorithm to 2**t steps (for t <= 96), then to attack a hash preimage problem of 192 bits, it requires a total of 2**(192-t) hash computations (rather than the 2**(192/2) hash computations 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) Quantum Computers (for t <= 96), with one of the Quantum Computers finding the preimage.
For example, if the adversary is willing to wait for 2**64 times the time taken by a hash computation (which is over 50 years if 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.
Hence, we expect that HSS/LMS based on these hash functions is secure against both classical and quantum computers,
even though, in both cases, the expected work effort is less (for the N=24 case) than against either SHA-256 or SHAKE256/256.
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.
HSS uses randomized hashing when signing a message. That is, when a message is being presented to be signed, the signer generates a random value C and includes that in what is prepended to the message. Because the attacker cannot predict this value, it is infeasible for anyone other than the signer to find a generic collision.
That is, practically speaking, a signature that is valid for two colliding messages is feasible only if the signer signed both messages.
For this to happen, a signer (that is, the one with the private key and who picks the random C value) would have to break the collision resistance in the hash function to generate those two colliding messages.
Note that this does not apply to someone who submits the messages for signing, only the signer could perform this.
This would result in a signature that would be valid for two different selected messages. This is a nonstandard assumption for signature schemes and is usually not a concern, as we need to assume that the signer is trusted to generate signatures for any message.
However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions the application needs to make is reduced; 128 bits for SHAKE256/256 and 96 bits for SHA-2/192 and SHAKE256/192.
Some cryptographers have raised the possibility of a multitarget attack (where the attacker has signatures from a large number of public keys, and succeeds if he can generate a forgery against any one of those public keys).
While no such method of attack has been proposed, the possibility cannot be excluded; if you use a large number of public keys, you may want to consider the possibility of some security loss if you use public keys with N=192.
If you use 2**K public keys, this security loss cannot be more than K bits of security.
Note on the version of SHAKE
FIPS 202 defines both SHAKE128 and SHAKE256. This specification selects SHAKE256, even though it is,
for large messages, less efficient. The reason is that SHAKE128 has a low upper bound on the difficulty
of finding preimages (due to the invertibility of its internal permutation), which would limit the strength
of HSS/LMS (whose strength is based on the difficulty of finding preimages). Hence, we specify the use of
SHAKE256, which has a considerably stronger preimage resistance.
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Intellectual Property Rights in IETF Technology
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Clarification of the Third Party Disclosure Procedure in RFC 3979
This document clarifies and updates a single sentence in RFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Guidelines for Writing an IANA Considerations Section in RFCs
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or 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 instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Leighton-Micali Hash-Based Signatures
This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.
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 research group and outside of it. The Acknowledgements section lists many of them.
Secure Hash Standard (SHS)
National Institute of Standards and Technology
SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
National Institute of Standards and Technology
Informative References
A fast quantum mechanical algorithm for database search
Analysis of a Proposed Hash-Based Signature Standard
Recommendation for Stateful Hash-Based Signature Schemes
National Institute of Standards and Technology
Test Cases
This section provides three test cases that can be used to verify or debug
an implementation, one for each hash function.
This data is formatted with the name of the
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
key or signature produces that public key or signature, and values
that do not fit within a single line are listed across successive
lines.
Test Case 1 Private Key for SHA-256/192
Test Case 1 Public Key for SHA-256/192
Test Case 1 Message for SHA-256/192
Test Case 1 Signature for SHA-256/192
Test Case 2 Private Key for SHAKE256/192
Test Case 2 Public Key for SHAKE256/192
Test Case 2 Message for SHAKE256/192
Test Case 2 Signature for SHAKE256/192
Test Case 3 Private Key for SHAKE256/256
Test Case 3 Public Key for SHAKE256/256
Test Case 3 Message for SHAKE256/256
Test Case 3 Signature for SHAKE256/256
Test Case 4 Private Key for for SHA256/192 with W=4
Test Case 4 Public Key for for SHA256/192 with W=4
Test Case 4 Message for for SHA256/192 with W=4
Test Case 4 Signature for SHA256/192 with W=4