]>
Additional Parameter sets for LMS Hash-Based SignaturesCisco Systems170 West Tasman DriveSan JoseCAUSAsfluhrer@cisco.comNIST100 Bureau DriveGaithersburgMDUSAquynh.dang@nist.gov
IRTF
Crypto Forum Research Group
This note extends LMS (RFC 8554) by defining parameter sets by including
additional hash functions. Hese include hash functions that result in signatures with significantly
smaller 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.
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 LMS (RFC8554)
stateful hash based signature method that reduce the size of the signature
significantly.
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.
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 .
This document defines a SHA-2 based hash function with a 192 bit output.
As such, we define SHA256/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.
It is the same procedure used to define SHA-224, except that we use the SHA-256 IV (rather than
using one dedicated to SHA256/192), and you truncate 64 bits, rather than 32.
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 SHA256/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 which varies per message; in addition, all hashes include the I identifier, which varies
depending on the public key.
Therefore, signing the same message by SHA256 and by SHA256/192 will not
result in the same value being hashed, and so the latter hash value is not a prefix of the former one.
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.
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 SHAKE-256 XOF, with the output being 192 bits, see FIPS 202 [FIPS202] for more detail.
Here is a table with the LM-OTS parameters defined that use the above hashes:
Parameter Set NameHnwplsidLMOTS_SHA256_N24_W1SHA256/1922412008TBD1LMOTS_SHA256_N24_W2SHA256/1922421016TBD2LMOTS_SHA256_N24_W4SHA256/192244514TBD3LMOTS_SHA256_N24_W8SHA256/192248260TBD4LMOTS_SHAKE_N32_W1SHAKE256-2563212657TBD5LMOTS_SHAKE_N32_W2SHAKE256-2563221336TBD6LMOTS_SHAKE_N32_W4SHAKE256-256324674TBD7LMOTS_SHAKE_N32_W8SHAKE256-256328340TBD8LMOTS_SHAKE_N24_W1SHAKE256-1922412008TBD9LMOTS_SHAKE_N24_W2SHAKE256-1922421016TBD10LMOTS_SHAKE_N24_W4SHAKE256-192244514TBD11LMOTS_SHAKE_N24_W8SHAKE256-192248260TBD12
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
SHA256/192, SHAKE256-256 and SHAKE256-192 hash functions defined in .
Remember that the C message randomizer (which is included in the signature) is the size of the hash n,
and so it shrinks from 32 bytes to 24 bytes for those the parameter sets that use either SHA256/192 or SHAKE256-192.
Here is a table with the LM parameters defined that use SHA259/192, SHAKE256-256 and SHAKE256-192 hash functions:
Parameter Set NameHmhidLMS_SHA256_M24_H5SHA256/192245TBD13LMS_SHA256_M24_H10SHA256/1922410TBD14LMS_SHA256_M24_H15SHA256/1922415TBD15LMS_SHA256_M24_H20SHA256/1922420TBD16LMS_SHA256_M24_H25SHA256/1922425TBD17LMS_SHAKE_M32_H5SHAKE256-256325TBD18LMS_SHAKE_M32_H10SHAKE256-2563210TBD19LMS_SHAKE_M32_H15SHAKE256-2563215TBD20LMS_SHAKE_M32_H20SHAKE256-2563220TBD21LMS_SHAKE_M32_H25SHAKE256-2563225TBD22LMS_SHAKE_M24_H5SHAKE256-192245TBD23LMS_SHAKE_M24_H10SHAKE256-1922410TBD24LMS_SHAKE_M24_H15SHAKE256-1922415TBD25LMS_SHAKE_M24_H20SHAKE256-1922420TBD26LMS_SHAKE_M24_H25SHAKE256-1922425TBD27
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
SHA256/192, SHAKE256-256 and SHAKE256-192 hash functions defined in .
Switching to a 192 bit hash affects the signature size, the computation time, and the security strength.
The major reason for considering these truncated parameter sets is that they cause the signatures
to shrink considerably.
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
ParmSetWinternitz256 bit hash192 bit hash1542672162415816161024204283217442081776114415/1045236317215/1083124197215/1545396329215/1583284209220/1045396329220/1083284209220/1545556341220/15834442212ParmSet: this is the height of the Merkle tree(s); parameter sets listed as
a single integer have L=1, and consist 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 (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 SHA256 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 SHA256/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.
In addition, for SHA256-192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192 bit hash.
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 SHA256-based parameter sets;
any performance delta would depend solely on the implementation and whether they can generate SHAKE hashes faster than SHA-256 ones.
[TO BE REMOVED: The entries from , namely
LMOTS_SHA256_N24_W1 through LMOTS_SHAKE_N24_W8 ,
should be inserted into https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml#lm-ots-signatures ]
[TO BE REMOVED: The entries from , namely
LMS_SHA256_M24_H5 through LMS_SHAKE_M24_H25
should be inserted into https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml#leighton-micali-signatures-1 ]
Until IANA assigns the codepoints, we will (for testing purposes only) use the
following private use code points to do any necessary interoperability testing.
Such an implementation must change to the IANA-assigned code points when they
become available.
Parameter Set NameTemporary CodepointLMOTS_SHA256_N24_W10xE0000001LMOTS_SHA256_N24_W20xE0000002LMOTS_SHA256_N24_W40xE0000003LMOTS_SHA256_N24_W80xE0000004LMOTS_SHAKE_N32_W10xE0000005LMOTS_SHAKE_N32_W20xE0000006LMOTS_SHAKE_N32_W40xE0000007LMOTS_SHAKE_N32_W80xE0000008LMOTS_SHAKE_N24_W10xE0000009LMOTS_SHAKE_N24_W20xE000000ALMOTS_SHAKE_N24_W40xE000000BLMOTS_SHAKE_N24_W80xE000000CLMS_SHA256_M24_H50xE0000001LMS_SHA256_M24_H100xE0000002LMS_SHA256_M24_H150xE0000003LMS_SHA256_M24_H200xE0000004LMS_SHA256_M24_H250xE0000005LMS_SHAKE_M32_H50xE0000006LMS_SHAKE_M32_H100xE0000007LMS_SHAKE_M32_H150xE0000008LMS_SHAKE_M32_H200xE0000009LMS_SHAKE_M32_H250xE000000ALMS_SHAKE_M24_H50xE000000BLMS_SHAKE_M24_H100xE000000CLMS_SHAKE_M24_H150xE000000DLMS_SHAKE_M24_H200xE000000ELMS_SHAKE_M24_H250xE000000F
The strength of a signature that uses the SHA256/192, SHAKE256-256 and SHAKE256-192 hash functions is based
on the difficultly in finding preimages or second preimages to those hash functions.
The case of SHAKE256-256 is essentially the same as the existing SHA-256 based signatures; the difficultly
of finding preimages is essentially the same, and so they have (barring unexpected cryptographical advances)
essentially the same level of security.
The case of SHA256/192 and SHAKE256-192 requires closer analysis.
For a classical (nonquantum) computer, they have no known attack better than performing hashes
of a large number of distinct preimages; as a successful attack has a high probability
of requiring nearly 2**192 hash computations (for either SHA256/192 or SHAKE256-192).
These can be taken as the expected work effort, and would appear to be completely
infeasible in practice.
For a Quantum Computer, they could in theory use a Grover's algorithm to reduce
the expected complexity required to circa 2**96 hash computations (for N=24). On the other
hand, to implement 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.
Hence, we expect that 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 SHA256 or SHAKE256-256.
FIPS 202 defines both SHAKE-128 and SHAKE-256. This specification selects SHAKE-256, even though it is,
for large messages, less efficient. The reason is that SHAKE-128 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 LMS (whose strength is based on the difficulty of finding preimages). Hence, we specify the use of
SHAKE-256, which has a considerably stronger preimage resistance.
&rfc2119;
&rfc3979;
&rfc4879;
&rfc5226;
&rfc8554;
Secure Hash Standard (SHS)National Institute of Standards and TechnologySHA-3 Standard: Permutation-Based Hash and Extendable-Output FunctionsNational Institute of Standards and TechnologyA fast quantum mechanical algorithm for database search
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.