Internet-Draft Additional HSS/LMS Signatures June 2024
Fluhrer & Dang Expires 28 December 2024 [Page]
Crypto Forum Research Group
Intended Status:
S. Fluhrer
Cisco Systems
Q. Dang

Additional Parameter sets for HSS/LMS Hash-Based Signatures


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 28 December 2024.

Table of Contents

1. 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 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).

This document is intended to be compatible with the NIST document [NIST_SP_800-208].

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.

Quick note about the distinction between HSS and LMS. LMS is a stateful hash based signature scheme that is 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 as LMS signatures. This document uses the term HSS/LMS to cover both the pedantic and the common meanings.

2. 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 [RFC8174].

3. Additional Hash Function Definitions

This section defines three hash functions that will be used in Section 4 and Section 5. These hash functions will be used where SHA-256 is used in the original parameter sets from RFC 8554. The hash function used is specified by the parameter set which is selected.

3.1. 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 [FIPS180]. 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:

  SHA-256("abc")     = ba7816bf 8f01cfea 414140de 5dae2223
                       b00361a3 96177a9c b410ff61 f20015ad
  SHA-256/192("abc") = ba7816bf 8f01cfea 414140de 5dae2223
                       b00361a3 96177a9c

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 [RFC8554] 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.

3.2. 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 [FIPS202] for more detail.

3.3. 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 [FIPS202] for more detail.

4. Additional LM-OTS Parameter Sets

Here is a table with the LM-OTS parameters defined that use the above hashes:

Table 1
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

These values are additions to the entries in Table 1 of RFC 8554.

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 Section 3.

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.

5. 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:

Table 2
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

These values are additions to the entries in Table 2 of RFC 8554.

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 Section 3.

6. Usage for these additional hash functions within HSS

To use the additional hash functions within HSS, you would use the appropriate LMOTS id from Table 1 and the appropriate LMS id from Table 2, 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.

7. 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 Section 9 for a discussion of the security strength.

The impact on signature size and computation time is based on two effects:

  1. Each hash that appears in the signature is shorter.
  2. We need fewer Winternitz chains (because LM-OTS signs a shorter value).

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).

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:

Table 3
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 Table 2. 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, which is the parameter "w" from Table 1. 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 shows 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.

8. Parameter Set Selection

This document, along with [RFC8554], 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 comes 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 or if one of the two happens to give better hashing performance on your platform.

9. 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 [Katz16], 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 [Grover96] to reduce the expected complexity to circa 2**96 hash computations (for N=24). On the other hand, implementing Grover's algorithm with this number of hash computations would require performing circa 2**96 hash computations in succession, which will take more time than is likely to be acceptable to any attacker. To speed this up, the attacker would need to run a number of instances of Grover's algorithm in parallel. This would necessarily increase the total work effort required, and to 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.

SHA-256 is subject to a length extension attack. In this attack, if the attacker is given the hash value of an unknown message (and the message length) then the attacker can compute the hash of the message appended with certain strings (even though the attacker does not know the contents of the initial part of the modified message). This would appear to be irrelevant to HSS for two reasons:

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.

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 of 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 assume that the signer is trusted to generate signatures for any message. However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced; 128 bits for SHAKE256/256 and 96 bits for SHA-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=24. If you use 2**K public keys, this security loss cannot be more than K bits of security.

9.1. Note on the version of SHAKE

FIPS 202 [FIPS202] 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.

10. IANA considerations

IANA has already assigned the code points for both the additional parameter sets in Section 4 (in the IANA table LM-OTS Signatures) and Section 5 (in the IANA table Leighton-Micali Signatures (LMS)). IANA is requested to update the references in those tables to the new parameter sets (which currently point to draft-fluhrer-lms-more-parm-sets-04) to point to this RFC.

11. Acknowledgements

We would like to thank Russ Housley, Andrey Jivsov, Virendra Kumar, Thomas Pornin and Stanislav Smyshlyaev for their insightful and helpful reviews.

12. References

12.1. Normative References

National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS 180-4, .
National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS 202, .
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", RFC 3979, DOI 10.17487/RFC3979, , <>.
Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", RFC 4879, DOI 10.17487/RFC4879, , <>.
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, DOI 10.17487/RFC174, , <>.
McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, , <>.

12.2. Informative References

Grover, L.K., "A fast quantum mechanical algorithm for database search", 28th ACM Symposium on the Theory of Computing p. 212, .
Katz, J., "Analysis of a Proposed Hash-Based Signature Standard", SSR 2016: Security Standardisation Research pp. 261-273, DOI 10.1007/978-3-319-49100-4_12, , <>.
National Institute of Standards and Technology, "Recommendation for Stateful Hash-Based Signature Schemes", NIST SP 800-208, .

Appendix A. 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

(note: procedure in Appendix A of [RFC8554] is used)
SEED        000102030405060708090a0b0c0d0e0f
I           202122232425262728292a2b2c2d2e2f

Test Case 1 Public Key for SHA-256/192

HSS public key
levels      00000001
LMS type    0000000a                         # LMS_SHA256_M24_H5
LMOTS type  00000008                         # LMOTS_SHA256_N24_W8
I           202122232425262728292a2b2c2d2e2f
K           2c571450aed99cfb4f4ac285da148827

Test Case 1 Message for SHA-256/192

Message     54657374206d65737361676520666f72  |Test message for|
            205348413235362d3139320a          | SHA-256/192.|

Test Case 1 Signature for SHA-256/192

HSS signature
Nspk        00000000
LMS signature
q           00000005
LMOTS signature
LMOTS type  00000008                         # LMOTS_SHA256_N24_W8
C           0b5040a18c1b5cabcbc85b047402ec62
y[0]        e13b9f0875f09361dc77fcc4481ea463
y[1]        614b835b4694c059f12d3aedd34f3db9
y[2]        3d0648c0537b7a50e433d7ea9d6672ff
y[3]        8eb3f3b23fd2061e4d0b38f832860ae7
y[4]        5dcf1bfb56fe16ff723627612f9a48f7
y[5]        1e919d99919c8db48168838cece0abfb
y[6]        e8ec10c63d8bf80d36498dfc205dc45d
y[7]        90177cf5137b8bbf7bcb67a46f86f26c
y[8]        a099a98b0b3f96d5ac8ac375d8da2a7c
y[9]        5b9218359cddab4cf8ccc6d54cb7e1b3
y[10]       63d2fc6742a7177876476a324b03295b
y[11]       0583c1b2b616aad0f31cd7a4b1bb0a51
y[12]       f8866e2528a159df3d6ce244d2b6518d
y[13]       927054a1e1620b5b02aab0c8c10ed48a
y[14]       ff88bff461dac51e7ab4ca75f47a6259
y[15]       39f61ae2a8186ae4e3c9bfe0af2cc717
y[16]       edb0665115f2067a46843a4cbbd297d5
y[17]       3b3d894e8595a6526073f02ab0f08b99
y[18]       7e5545e6f9ad5f9c183abd043d5acd6e
y[19]       67b468720a4b8b92ddfe7960998bb7a0
y[20]       413f7b2aecd39a30cec527b4d9710c44
y[21]       1c0457125da0fa4429c07dad859c846c
y[22]       770b089cfede6f651e86dd7c15989c8b
y[23]       fd862323072b827cee7a7e28e4e2b999
y[24]       7aef9187c96b3f5b79fb98bc76c3574d
y[25]       ef3a54c4155fe3ad817749629c30adbe
LMS type    0000000a                         # LMS_SHA256_M24_H5
path[0]     e9ca10eaa811b22ae07fb195e3590a33
path[1]     38d19f152182c807d3c40b189d3fcbea
path[2]     332d33ae0b761a2a8f984b56b2ac2fd4
path[3]     19c7aa7e9eee96504b0e60c6bb5c942d
path[4]     5871cffd131d0e04ffe5065bc7875e82

Test Case 2 Private Key for SHAKE256/192

(note: procedure in Appendix A of [RFC8554] is used)
SEED        303132333435363738393a3b3c3d3e3f
I           505152535455565758595a5b5c5d5e5f

Test Case 2 Public Key for SHAKE256/192

HSS public key
levels      00000001
LMS type    00000014                         # LMS_SHAKE256_N24_H5
LMOTS type  00000010                         # LMOTS_SHAKE256_N24_W8
I           505152535455565758595a5b5c5d5e5f
K           db54a4509901051c01e26d9990e55034

Test Case 2 Message for SHAKE256/192

Message     54657374206d65737361676520666f72  |Test message for|
            205348414b453235362d3139320a      | SHAKE256/192.|

Test Case 2 Signature for SHAKE256/192

HSS signature
Nspk        00000000
LMS signature
q           00000006
LMOTS signature
LMOTS type  00000010                         # LMOTS_SHAKE256_N24_W8
C           84219da9ce9fffb16edb94527c6d1056
y[0]        208e62fc4fbe9d85deb3c6bd2c01640a
y[1]        511234a6a1a50108091c034cb1777e02
y[2]        a498e4200c0a0c1bf5d100cdb97d2dd4
y[3]        a570071a043956112c6deebd1eb3a7b5
y[4]        fddb0ec2d9094bfbc889ea15c3c7b9be
y[5]        35b9acab66a2e9631e426e4e99b733ca
y[6]        c54a7e703d8162e736875cb6a455d4a9
y[7]        e402b47036dc3770f4a1dd0a559cb478
y[8]        9d1ac2de94d731ee4ca79cff454c811f
y[9]        2005e84b6e15378446b1ca691efe491e
y[10]       aba5e2eb3c306811c240ba2280292382
y[11]       83ba5bc9d69d999a7db8f749770c3c04
y[12]       7921465b61b3f847b13b2635a45379e5
y[13]       0ac767f7f30175f9f7a140257e218be3
y[14]       02c4fa7c90d8a592945c66e86a76defc
y[15]       0faaa10077c74c94895731585c8f900d
y[16]       0ebe2b5eb3ef8019ece3e1ea7223eb79
y[17]       25c4b8a05f205c8befeef11ceff12825
y[18]       9f73f3e3a74bb4b3c0d8ca2abd0e1c2c
y[19]       e87bcfb1305b3c069e6d385569a4067e
y[20]       4a58aab96e2fa883a9a39e1bd45541ee
y[21]       e66dc8538b2dab05aee5efa6b3b2efb3
y[22]       afff9a3e636dbba864a5bffa3e28d13d
y[23]       88c4627f206ab2b465084d6b780666e9
y[24]       f1ae8f1035087f5028f14affcc5fffe3
y[25]       eac9062608c7d87708f1723f38b23237
LMS type    00000014                         # LMS_SHAKE256_N24_H5
path[0]     dd4bdc8f928fb526f6fb7cdb944a7eba
path[1]     27096a5007d82f79d063acd434a04e97
path[2]     b4ec7c87a5ed10c881928fc6ebce6dfc
path[3]     7ca9a9dd5f9f573704d5e6cf22a43b04
path[4]     cb495ba265f465c56291a902e62a461f

Test Case 3 Private Key for SHAKE256/256

(note: procedure in Appendix A of [RFC8554] is used)
SEED        606162636465666768696a6b6c6d6e6f
I           808182838485868788898a8b8c8d8e8f

Test Case 3 Public Key for SHAKE256/256

HSS public key
levels      00000001
LMS type    0000000f                         # LMS_SHAKE256_N32_H5
LMOTS type  0000000c                         # LMOTS_SHAKE256_N32_W8
I           808182838485868788898a8b8c8d8e8f
K           9bb7faee411cae806c16a466c3191a8b

Test Case 3 Message for SHAKE256/256

Message     54657374206d657361676520666f7220  |Test mesage for |
            5348414b453235362d3235360a        |SHAKE256/256.|

Test Case 3 Signature for SHAKE256/256

HSS signature
Nspk        00000000
LMS signature
q           00000007
LMOTS signature
LMOTS type  0000000c                         # LMOTS_SHAKE256_N32_W8
C           b82709f0f00e83759190996233d1ee4f
y[0]        16b228118c62b96c9c77678b33183730
y[1]        1d69c00129680b67e75b3bd7d8aa5c8b
y[2]        864b302ff321f9c4b8354408d0676050
y[3]        1403160fb45450d61a9c8c81f6bd69bd
y[4]        34ecc66dc88e10c6e0142942d4843f70
y[5]        caeef21303f8ac58b9f200371dc9e41a
y[6]        5b3ed19d847bd0a737177263cbc1a226
y[7]        ceb3bbcbd25228dda8306536376f8793
y[8]        7352919995b74404cc69a6f3b469445c
y[9]        3da3571ef70f805c9cc54b8e501a98b9
y[10]       769a9d422786def59700eef3278017ba
y[11]       36fbec4178d2bda3ad31e1644a2bcce2
y[12]       0d5beab0fb805e1945c41834dd6085e6
y[13]       ff123abe64dae8dabb2e84ca705309c2
y[14]       6f5e3bb8813997881b6a33cac0714e4b
y[15]       e773139ae377f5ba19ac86198d485fca
y[16]       bfe2d86b12778164436ab2659ba86676
y[17]       f72c5cb31f5a0b1d926324c26e67d4c3
y[18]       cf440f52ca9b5b9b99aba8a6754aae2b
y[19]       c36131c8991f0cc2ba57a15d35c91cf8
y[20]       bd4792b924b839332a64788a7701a300
y[21]       4fa87920b645e42aa2fecc9e21e000ca
y[22]       9376430f355aaf96a0a13d13f2419141
y[23]       0ea7255214ce11238605de2f000d2001
y[24]       49217cdf52f307172e2f6c7a2a4543e1
y[25]       14ed22483f2889f61e62b6fb78f5645b
y[26]       b61958786c97bd52fa199c27f6bb4d68
y[27]       d6e852cf6bc773ffd4c07ee2d6cc55f5
y[28]       cab1cc285faf6793ffad7a8c341a49c5
y[29]       81a68e21d748a7e7b1df8a593f3894b2
y[30]       1db33bbd390d2c04401c39b253b78ce2
y[31]       de256890804d83d6ec5ca3286f1fca9c
y[32]       9bbc69e2fd8618e9db3bdb0af13dda06
y[33]       19f55e9af11ae3d5614b564c642dbfec
LMS type    0000000f                         # LMS_SHAKE256_N32_H5
path[0]     71d585a35c3a908379f4072d070311db
path[1]     1329978a05d5e815cf4d74c1e547ec4a
path[2]     ae61ba57e5342e9db12caf6f6dbc5253
path[3]     1c12b9ffc3bcb1d3ac8589777655e22c
path[4]     ad6bfc337db69849e54411df8920c228

Test Case 4 Private Key for for SHA256/192 with W=4

(note: procedure in Appendix A of [RFC8554] is used)
SEED        202122232425262728292a2b2c2d2e2f
I           404142434445464748494a4b4c4d4e4f

Test Case 4 Public Key for for SHA256/192 with W=4

HSS public key
levels      00000001
LMS type    0000000d                         # LMS_SHA256_M24_H20
LMOTS type  00000007                         # LMOTS_SHA256_N24_W4
I           404142434445464748494a4b4c4d4e4f
K           9c08a50d170406869892802ee4142fcd

Test Case 4 Message for for SHA256/192 with W=4

Message     54657374206d65737361676520666f72  |Test message for|
            205348413235362f31393220773d34    | SHA256/192 w=4|

Test Case 4 Signature for SHA256/192 with W=4

HSS signature
Nspk        00000000
LMS signature
q           00000064
LMOTS signature
LMOTS type  00000007                         # LMOTS_SHA256_N24_W4
C          853fa6e1a65fef076acd2485505b93be
y[0]       1887f26f4bcdb6ac0337b76fa5d66038
y[1]       7c336df2134c0a981f1ec2bb7baee516
y[2]       45a7f2be4fd84a604ae3743efc609ee0
y[3]       50e877b75d3cae63e9d5c15a32bb3cd1
y[4]       dd1ee3cfbe18f1cbd06ef3e7af34b184
y[5]       07ed525cec120d054b403c61a7e5034f
y[6]       d4b6bbc0ae6cd3fe9993d583ee06f403
y[7]       13f5088731b91a98491fa3adf1b322bc
y[8]       6bdfe07a6fd48e6d951515758cd64349
y[9]       a338ec235871dd564998d07d9b1b1b8d
y[10]      8fe195d129faddb12d543b86b0ab8cf6
y[11]      d03f793b42909272f688e4ef6d46e82b
y[12]      9920b2e6f19faf75c623242f1f2c549f
y[13]      20d97baea507467bb2da79f132bbe15b
y[14]      ebca2597de9d55bd83bcae5c28a85259
y[15]      c8afa0b10bd08a8f9ed9b1ede3377075
y[16]      7bfc9ece0d4cd6972059329419feaf3b
y[17]      b1cea8950aea4af870d1a3a3909ebc5a
y[18]      f95093e83cb36a9c1d6f13add19268ac
y[19]      a57fdb0141d55d937dd6ebb08fee8a5c
y[20]      17e6c57be5e62a52a6b1b986730d3a3a
y[21]      6bc7b636eb2a5c4f2a635ae5bada5418
y[22]      9334fac89d420d6ad5a2e1df95d26a1b
y[23]      fdf2d6e8394caf8a4be699b8afa38e52
y[24]      5bf33d3ca3a35bc96987282bd513a8f6
y[25]      2b3bf573fa275449d8d49eb30bed2bb1
y[26]      2ea3dd37acd46c713cc2ac9d01a20a30
y[27]      1cad7761bf4130a6565572766026509d
y[28]      218a4e137a7ce063b546a35c52510f0e
y[29]      e43b37c5ffa23da7a7fc254324a3de70
y[30]      e5a747e5146fd804a47719803c185b38
y[31]      073d86b2307cf90c6c3ef9271f2d53df
y[32]      37a9025965f70b4616673228e98644be
y[33]      350259e7f697408cdf8cf81a3e774162
y[34]      cb5ceb7c8c097cec505091a3ee3a826c
y[35]      a318dac10250ba940e51e79a3f572fb3
y[36]      946e6387f9a8c705d945c653f2684655
y[37]      91bef9898292fa272fb8761f066c23d8
y[38]      9c843b796855c51ad1272e9264acd203
y[39]      dfcd7c22366a36495349391dbf000106
y[40]      33e48f1b058a6cb3e71bbb8df3e90406
y[41]      ceeba410b33b07716ffc18d6eab75f2d
y[42]      3ed66f2d8f7c5abe59e87d4500965e34
y[43]      827aaa22b1c72a15293c7400e02aaefc
y[44]      e6228e7ad19d1450c23434f1e45043dc
y[45]      44d4162aa651333287cd8bf8fac41c78
y[46]      dc5a2f80205c043b22e540a29f0ea0a5
y[47]      96fc4bb4ac2e875322ab115db479fe97
y[48]      ad3b758fff83af1b9c48e90ca39366f4
y[49]      786a9217723945a1ac1a66af7def4f8b
y[50]      ac91ac9d603807f8bab105b46d315d4c
LMS type    0000000d                         # LMS_SHA256_M24_H20
path[0]    13d1a8ef00c5811c15c4d774fdcf7515
path[1]    b6a54f12c165963dd5690cc9842b0e21
path[2]    832155599d00aced84bb3b59170396f7
path[3]    cf9367d6e99d3d5be3555d7156b004f2
path[4]    9b9b46a666672aa8ee662c3a0456a9ad
path[5]    577dcd36dc5cdff34b864d0a32492a0a
path[6]    5b91ab2ab84f2333fb3e3b9acaecdac3
path[7]    25631ed6674cccb8c119acbd4992ab31
path[8]    5ab52fbc549430f8b403e4a2a51cc7f4
path[9]    708fd25bcd657a790e54718d97090624
path[10]   a44c4ba818a8dd2d242251265b023b82
path[11]   c4ada2b85a67988d406132c2ad899099
path[12]   0b406224411a59597e5dda0f31cd16c9
path[13]   074f43eb02273481bc324ded26c64f23
path[14]   34ca4afebfac2a689b4246c264241488
path[15]   c09d57dc1126291b2318810e0f44801c
path[16]   f44c9503a4c03c37417dc96422ba0849
path[17]   4fcab84276effec652ca77d7d47ac93c
path[18]   5587d1990ffaef737fced1f5cdd8f373
path[19]   b12302639f83a2d74c9fe30d305a942b

Authors' Addresses

Scott Fluhrer
Cisco Systems
170 West Tasman Drive
San Jose, CA
United States of America
Quynh Dang
100 Bureau Drive
Gaithersburg, MD
United States of America