]>
Hash-Based SignaturesCisco Systems13600 Dulles Technology DriveHerndon20171VAUSAmcgrew@cisco.comCisco Systems7025-2 Kit Creek RoadResearch Triangle Park27709-4987NCUSAmicurcio@cisco.comCisco Systems170 West Tasman DriveSan JoseCAUSAsfluhrer@cisco.com
IRTF
Crypto Forum Research Group
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 naturally resist side-channel attacks. Unlike
most 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.
One-time signature systems, and general purpose signature systems
built out of one-time signature systems, have been known since 1979
, were well studied in the 1990s , and have benefited from renewed attention
in the last decade. The characteristics of these signature systems
are small private and public keys and fast signature generation and
verification, but large signatures and moderately slow key generation (in comparison with RSA and ECDSA).
Private keys can be made very small by appropriate key generation,
for example, as described in Appendix A.
In recent years there has been interest in these systems because of
their post-quantum security
and their
suitability for compact verifier implementations.
This note describes the Leighton and Micali adaptation of the original
Lamport-Diffie-Winternitz-Merkle one-time signature system
and general
signature system with enough specificity to
ensure interoperability between implementations.
A signature system provides asymmetric message authentication. The
key generation algorithm produces a public/private key pair. A
message is signed by a private key, producing a signature, and a
message/signature pair can be verified by a public key. A One-Time
Signature (OTS) system can be used to sign one message securely,
but will become insecure if more than one is signed with the same public/private key pair.
An N-time signature
system can be used to sign N or fewer messages securely. A Merkle
tree signature scheme is an N-time signature system that uses an OTS
system as a component.
In the Merkle scheme, a binary tree of height h is used to hold 2^h OTS key pairs.
Each interior node of the tree holds a value which is the hash of the values of its two children nodes.
The public key of the tree is the value of the root node (a recursive hash of the OTS public keys),
while the private key of the tree is the collection of all the OTS private keys,
together with the index of the next OTS private key to sign the next message with.
In this note we describe the Leighton-Micali Signature (LMS) system,
which is a variant of the Merkle scheme, and a Hierarchical Signature
System (HSS) built on top of it that can efficiently scale to larger
numbers of signatures.
In order to support signing a large number of messages on resource constrained systems,
the Merkle tree can be subdivided into a number of smaller trees.
Only the bottom-most tree is used to sign messages,
while trees above that are used to sign the public keys of their children.
For example, in the simplest case with 2 levels with both levels consisting of height h trees,
the root tree is used to sign 2^h trees with 2^h OTS key pairs, and each second level tree
has 2^h OTS key pairs, for a total of 2^(2h) bottom level key pairs, and so can sign 2^(2h) messages.
The advantage of this scheme is that only the active trees need to be instantiated, which
saves both time (for key generation) and space (for key storage).
On the other hand, using a multilevel signature scheme inceases the size of the signature,
as well as the signature verification time.
This note is structured as follows.
Notes on postquantum cryptography are discussed in .
Intellectual Property issues are discussed in .
The notation used within this note is defined in ,
and the public formats are described in .
The LM-OTS
signature system is described in , and the LMS
and HSS N-time signature systems are described in
and , respectively.
Sufficient detail is provided to ensure interoperability.
The rationale for the design decisions is given in .
The IANA registry for these signature
systems is described in .
Security considerations are presented in .
Comparison with another hash based signature algorithm (XMSS) is in .
This document represents the rough consensus of the CFRG.
All post-quantum algorithms documented by the Crypto Forum Research
Group (CFRG) are today considered ready for experimentation and
further engineering development (e.g., to establish the impact of
performance and sizes on IETF protocols). However, at the time of
writing, we do not have significant deployment experience with such
algorithms.
Many of these algorithms come with specific restrictions, e.g.,
change of classical interface or less cryptanalysis of proposed
parameters than established schemes. CFRG has consensus that all
documents describing post-quantum technologies include the above
paragraph and a clear additional warning about any specific
restrictions, especially as those might affect use or deployment of
the specific scheme. That guidance may be changed over time via
document updates.
Additionally, for LMS:
CFRG consensus is that we are confident in the cryptographic security
of the signature schemes described in this document against quantum
computers, given the current state of the research community's
knowledge about quantum algorithms. Indeed, we are confident that
the security of a significant part of the Internet could be made
dependent on the signature schemes defined in this document, if
developers take care of the following.
In contrast to traditional signature schemes, the signature schemes
described in this document are stateful, meaning the secret key
changes over time. If a secret key state is used twice, no
cryptographic security guarantees remain. In consequence, it becomes
feasible to forge a signature on a new message. This is a new
property that most developers will not be familiar with and requires
careful handling of secret keys. Developers should not use the
schemes described here except in systems that prevent the reuse of
secret key states.
Note that the fact that the schemes described in this document are
stateful also implies that classical APIs for digital signatures
cannot be used without modification. The API MUST be able to handle
a secret key state; in particular, this means that the API MUST allow
to return an updated secret key state.
This draft is based on U.S. patent 5,432,852, which was issued over twenty
years ago and is thus expired.
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 .
The LMS signing algorithm is stateful; it modifies and updates the
private key as a side effect of generating a signature. Once a
particular value of the private key is used to sign one message, it
MUST NOT be used to sign another.
The key generation algorithm takes as input an indication of the
parameters for the signature system. If it is successful, it
returns both a private key and a public key. Otherwise, it returns
an indication of failure.
The signing algorithm takes as input the message to be signed and
the current value of the private key. If successful, it returns a
signature and the next value of the private key, if there is such
a value. After the private key of an N-time signature system has
signed N messages, the signing algorithm returns the signature and
an indication that there is no next value of the private key that
can be used for signing. If unsuccessful, it returns an
indication of failure.
The verification algorithm takes as input the public key, a
message, and a signature, and returns an indication of whether or
not the signature and message pair is valid.
A message/signature pair is valid if the signature was returned by
the signing algorithm upon input of the message and the private key
corresponding to the public key; otherwise, the signature and
message pair is not valid with probability very close to one.
Bytes and byte strings are the fundamental data types. A single byte
is denoted as a pair of hexadecimal digits with a leading "0x". A
byte string is an ordered sequence of zero or more bytes and is
denoted as an ordered sequence of hexadecimal characters with a
leading "0x". For example, 0xe534f0 is a byte string with a length of
three. An array of byte strings is an ordered set, indexed starting at zero,
in which all strings have the same length.
Unsigned integers are converted into byte strings by representing them
in network byte order. To make the number of bytes in the
representation explicit, we define the functions u8str(X), u16str(X),
and u32str(X), which take a non-negative integer X as input and return
one, two, and four byte strings, respectively. We also make use of
the function strTou32(S), which takes a four-byte string S as input
and returns a non-negative integer; the identity u32str(strTou32(S)) =
S holds for any four-byte string S.
When a and b are real numbers, mathematical operators are defined as follows:
^ : a ^ b denotes the result of a raised to the power of b* : a * b denotes the product of a multiplied by b/ : a / b denotes the quotient of a divided by b% : a % b denotes the remainder of the integer division of a by b (with a and b being restricted to integers in this case)+ : a + b denotes the sum of a and b- : a - b denotes the difference of a and bAND : a AND b denotes the bitwise AND of the two nonnegative integers a and b (represented in binary notation)
The standard order of operations is used when evaluating arithmetic expressions.
When B is a byte and i is an integer, then B >> i denotes the logical
right-shift operation by i bit positions.
Similarly, B << i denotes the logical left-shift operation.
If S and T are byte strings, then S || T denotes the concatenation of
S and T. If S and T are equal length byte strings, then S AND T
denotes the bitwise logical and operation.
The i-th element in an array A is denoted as A[i].
If r is a non-negative real number, then we define the following functions:
ceil(r) : returns the smallest integer greater than or equal to rfloor(r) : returns the largest integer less than or equal to rlg(r) : returns the base-2 logarithm of r
If S is a byte string, then byte(S, i) denotes its i-th byte, where the index
starts at 0 at the left. Hence, byte(S, 0) is the leftmost byte of S, byte(S, 1) is the
second byte at the left and (assuming S is n bytes long) byte(S, n-1) is the rightmost byte of S.
In addition, bytes(S, i, j) denotes the
range of bytes from the i-th to the j-th byte, inclusive. For example, if
S = 0x02040608, then byte(S, 0) is 0x02 and bytes(S, 1, 2) is 0x0406.
A byte string can be considered to be a string of w-bit unsigned
integers; the correspondence is defined by the function coef(S, i, w) as follows:
The return value of coef is an unsigned integer.
If i is larger than the number of w-bit values in S, then
coef(S, i, w) is undefined, and an attempt to compute
that value MUST raise an error.
A typecode is an unsigned integer that is associated with a particular
data format. The format of the LM-OTS, LMS, and HSS signatures and
public keys all begin with a typecode that indicates the precise
details used in that format. These typecodes are represented
as four-byte unsigned integers in network byte order; equivalently,
they are XDR enumerations (see ).
This section defines LM-OTS signatures. The signature is used to validate
the authenticity of a message by associating a secret private key with
a shared public key. These are one-time signatures; each
private key MUST be used at most one time to sign any given message.
As part of the signing process, a digest of the original message is
computed using the cryptographic hash function H (see ), and the resulting digest is signed.
In order to facilitate its use in an N-time signature system, the
LM-OTS key generation, signing, and verification algorithms all take
as input parameters I and q.
The parameter I is a 16 byte string, which indicates which Merkle tree this LM-OTS is used with.
The parameter q is a 32 bit integer which indicates the leaf of the Merkle tree where the OTS public key appears.
These parameters are used as part of the security string, as listed in .
When the LM-OTS signature
system is used outside of an N-time signature system, the value I MAY be used to differentiate this one time
signatures from others; however the value q
MUST be set to the all-zero value.
The signature system uses the parameters n and w, which are both
positive integers. The algorithm description also makes use of the
internal parameters p and ls, which are dependent on n and w. These
parameters are summarized as follows:
n : the number of bytes of the output of the hash functionw : the width (in bits) of the Winternitz coefficients; that is, the number of bits from the hash or checksum that is used with a single Winternitz chain.
It is a member of the set { 1, 2, 4, 8 }p : the number of n-byte string elements that make up the LM-OTS signature.
This is a function of n and w; the values for the defined parameter sets are lited in Table 1; it can also be computed by the algorithm given in Appendix B.ls : the number of left-shift bits used in the checksum function Cksm (defined in )
H : a second-preimage-resistant cryptographic hash function that accepts byte strings of any length, and returns an n-byte string
For more background on the cryptographic security requirements on H, see
the .
The value of n is determined by the hash function selected for use as part
of the LM-OTS algorithm; the choice of this value has a strong effect
on the security of the system. The parameter w determines the length
of the Winternitz chains computed as a part of the OTS signature
(which involve 2^w-1 invocations of the hash function); it has little
effect on security. Increasing w will shorten the
signature, but at a cost of a larger computation to generate and
verify a signature. The values of p and ls are dependent on the
choices of the parameters n and w, as described in . A table illustrating various
combinations of n, w, p and ls, along with the resulting signature length, is provided in .
The value of w describes a space/time trade-off; increasing the value of w will
cause the signature to shrink (by decreasing the value of p)
while increasing the amount of time needed to
perform operations with it (generate the public key, generate and verify the
signature); in general, the LM-OTS signature is 4+n*(p+1) bytes long, and public
key generation will take p*(2^w-1)+1 hash computations (and signature generation
and verification will take approximately half that on average).
Parameter Set NameHnwplssig_lenLMOTS_SHA256_N32_W1SHA25632126578516LMOTS_SHA256_N32_W2SHA25632213364292LMOTS_SHA256_N32_W4SHA2563246742180LMOTS_SHA256_N32_W8SHA2563283401124
Here SHA256 denotes the SHA-256 hash fucntion defined in NIST standard .
The format of the LM-OTS private key is an internal matter to the implementation, and this document does not attempt to define it.
One possibility is that the private key may consist of a typecode indicating the
particular LM-OTS algorithm, an array x[] containing p n-byte strings,
and the 16-byte string I and the 4 byte string q. This private key MUST be used to
sign (at most) one message. The following algorithm shows pseudocode for
generating a private key.
An implementation MAY use a pseudorandom method to compute x[i], as
suggested in , page 46. The details of the
pseudorandom method do not affect interoperability, but the
cryptographic strength MUST match that of the LM-OTS algorithm.
provides an example of a pseudorandom method
for computing the LM-OTS private key.
The LM-OTS public key is generated from the private key by iteratively
applying the function H to each individual element of x, for 2^w - 1
iterations, then hashing all of the resulting values.
The public key is generated from the private key using the following
algorithm, or any equivalent process.
The public key is the value returned by Algorithm 1.
A checksum is used to ensure that any forgery attempt that manipulates
the elements of an existing signature will be detected.
This checksum is needed because an attacker can freely advance any of the Winternitz chains.
That is, if this checksum were not present, then an attacker who could find a hash
that has every digit larger than the valid hash could replace it
(and adjust the Winternitz chains).
The security
property that it provides is detailed in .
The checksum function Cksm is defined as follows, where S denotes
the n-byte string that is input to that function, and the value
sum is a 16-bit unsigned integer:
Because of the left-shift operation, the rightmost bits of
the result of Cksm will often be zeros. Due to the value of p, these
bits will not be used during signature generation or
verification.
The LM-OTS signature of a message is generated by first prepending the
LMS key identifier I, the LMS leaf identifier q, the value D_MESG (0x8181) and the randomizer C to the message,
then computing the hash, and then concatenating
the checksum of the hash to the hash itself, then considering the
resulting value as a sequence of w-bit values, and using each of the
w-bit values to determine the number of times to apply the function H
to the corresponding element of the private key. The outputs of the
function H are concatenated together and returned as the signature.
The pseudocode for this procedure is shown below.
The signature is the string returned by Algorithm 3. specifies the typecode and more formally
defines the encoding and decoding of the string.
In order to verify a message with its signature (an array of n-byte
strings, denoted as y), the receiver must "complete" the chain of
iterations of H using the w-bit coefficients of the string
resulting from the concatenation of the message hash and its
checksum. This computation should result in a value that matches the
provided public key.
The Leighton-Micali Signature (LMS) method can sign a potentially large
but fixed number of messages. An LMS system uses two cryptographic
components: a one-time signature method and a hash function. Each LMS
public/private key pair is associated with a perfect binary tree, each
node of which contains an m-byte value, where m is the output length of the
hash function. Each leaf of the tree
contains the value of the public key of an LM-OTS public/private key
pair. The value contained by the root of the tree is the LMS public
key. Each interior node is computed by applying the hash function to
the concatenation of the values of its children nodes.
Each node of the tree is associated with a node number, an unsigned
integer that is denoted as node_num in the algorithms below, which
is computed as follows. The root node has node number 1; for each
node with node number N < 2^h (where h is the height of the tree), its left child has node number
2*N, while its right child has node number 2*N+1. The result of
this is that each node within the tree will have a unique node
number, and the leaves will have node numbers 2^h, (2^h)+1, (2^h)+2,
..., (2^h)+(2^h)-1. In general, the j-th node at level i has node
number 2^i + j. The node number can conveniently be computed when
it is needed in the LMS algorithms, as described in those
algorithms.
An LMS system has the following parameters:
h : the height of the tree, and
m : the number of bytes associated with each node.
H : a second-preimage-resistant cryptographic hash function that accepts byte strings of any length, and
returns an m-byte string.
There are 2^h leaves in the tree.
The overall strength of the LMS signatures is governed by the weaker of the hash function used within the LM-OTS
and the hash function used within the LMS system.
In order to minimize the risk, these two hash functions SHOULD be the same
(so that an attacker could not take advantage of the weaker hash function choice).
NameHmhLMS_SHA256_M32_H5SHA256325LMS_SHA256_M32_H10SHA2563210LMS_SHA256_M32_H15SHA2563215LMS_SHA256_M32_H20SHA2563220LMS_SHA256_M32_H25SHA2563225
The format of the LMS private key is an internal matter to the implementation, and this document does not attempt to define it.
One possibility is that it may consist of an array OTS_PRIV[] of 2^h LM-OTS
private keys, and the leaf number q of the next LM-OTS private key
that has not yet been used. The q-th element of OTS_PRIV[] is
generated using Algorithm 0 with the identifiers I, q.
The leaf number q is initialized to zero when the LMS private key is
created. The process is as follows:
An LMS private key MAY be generated pseudorandomly from a secret
value, in which case the secret value MUST be at least m bytes long, be
uniformly random, and MUST NOT be used for any other purpose than
the generation of the LMS private key. The details of how this
process is done do not affect interoperability; that is, the public
key verification operation is independent of these details.
provides an example of a pseudorandom method
for computing an LMS private key.
The signature generation logic uses q as the next leaf to use, hence
step 4 starts it off at the left-most one. Because the signature
proces increments q after the signature operation, the first signature
will have q=0.
An LMS public key is defined as follows, where we denote the public
key final hash value (namely, the K value computed in Algorithm 1)
associated with the i-th LM-OTS private key as OTS_PUB_HASH[i],
with i ranging from 0 to (2^h)-1. Each instance of an LMS
public/private key pair is associated with a balanced binary tree,
and the nodes of that tree are indexed from 1 to 2^(h+1)-1. Each
node is associated with an m-byte string, and the string for the r-th
node is denoted as T[r] and is defined as
When we have r >= 2^h, then we are processing a leaf node (and thus hashing only a single LM-OTS public key).
When we have r < 2^h, then we are processing an internal node, that is, a node with two child nodes that we need to combine.
The LMS public key is the string
specifies the format of the type variable.
The value otstype is the parameter set for the LM-OTS public/private keypairs used.
The value I is the private key identifier,
and is the value used for all computations for the same
LMS tree. The value T[1] can be computed via recursive
application of the above equation, or by any equivalent method. An
iterative procedure is outlined in .
An LMS signature consists of
the number q of the leaf associated with the LM-OTS signature,
as a four-byte unsigned integer in network byte order,
an LM-OTS signature,
a typecode indicating the particular LMS algorithm,
an array of h m-byte values that is associated with the path
through the tree from the leaf associated with the LM-OTS
signature to the root.
Symbolically, the signature can be represented as
specifies the typecode and
more formally defines the format.
The array for a tree with height h will have h values
and contains the values of the siblings of (that is, is adjacent to) the nodes on the path from the leaf to the root,
where the sibling to node A is the other node which shares node A's parent.
In the signature, 0 is counted from the bottom level of the tree, and so
path[0] is the value of the node adjacent to leaf node q;
path[1] is the second level node that is adjacent to leaf node q's parent,
and so up the tree until we get to path[h-1], which is the value of the
next-to-the-top level node that leaf node q does not reside in.
Below is a simple example of the authentication path for h=3 and q=2.
The leaf marked OTS is the one time signature which is used to sign the
actual message. The nodes on the path from the OTS public key to the
root are marked with a *, while the nodes that are used within the path array are marked with a **.
The values in the path array are those
nodes which are siblings of the nodes on the path; path[0] is the
leaf** node that is adjacent to the OTS public key (which is the
start of the path); path[1] is the T[4]** node which is the sibling of the second node T[5]* on
the path, and path[2] is the T[3]** node which is the sibling of the third node T[2]* on the path.
The idea behind this authentication path is that it allows us to validate
the OTS hash with using h path array values and hash computations.
What the verifier does is recompute the hashes up the path; first, he hashes
the given OTS and path[0] value, giving a tentative T[5]' value. Then, he
hashes his path[1] and tentative T[5]' value to get a tentative T[2]' value.
Then, he hashes that and the path[2] value to get a tentative Root' value.
If that value is the known public key of the Merkle tree, then we can assume that
the value T[2]' he got was the correct T[2] value in the original tree, and so the T[5]'
value he got was the correct T[5] value in the original tree, and so the OTS public
key is the same as in the original, and hence is correct.
To compute the LMS signature of a message with an LMS private key,
the signer first computes the LM-OTS signature of the message
using the leaf number of the next unused LM-OTS private key. The
leaf number q in the signature is set to the leaf number of the LMS
private key that was used in the signature. Before releasing the
signature, the leaf number q in the LMS private key MUST be
incremented, to prevent the LM-OTS private key from being used
again. If the LMS private key is maintained in nonvolatile
memory, then the implementation MUST ensure that the incremented
value has been stored before releasing the signature.
The issue this tries to prevent is a scenario where a) we generate
a signature, using one LM-OTS private key, and release it to the
application, b) before we update the nonvolatile memory, we crash,
and c) we reboot, and generate a second signature using the same
LM-OTS private key; with two different signatures using the same
LM-OTS private key, someone could potentially generate a forged
signature of a third message.
The array of node values in the signature MAY be computed in any
way. There are many potential time/storage tradeoffs that can be
applied. The fastest alternative is to store all of the nodes of
the tree and set the array in the signature by copying them; pseudocode
to do so appears in Appendix D. The
least storage intensive alternative is to recompute all of the
nodes for each signature. Note that the details of this procedure
are not important for interoperability; it is not necessary to
know any of these details in order to perform the signature
verification operation. The internal nodes of the tree need not
be kept secret, and thus a node-caching scheme that stores only
internal nodes can sidestep the need for strong protections.
Several useful time/storage tradeoffs are described in the
'Small-Memory LM Schemes' section of .
An LMS signature is verified by first using the LM-OTS signature
verification algorithm (Algorithm 4b) to compute the LM-OTS public key
from the LM-OTS signature and the message. The value of that public
key is then assigned to the associated leaf of the LMS tree, then the
root of the tree is computed from the leaf value and the array path[]
as described in Algorithm 6 below. If the root value matches the
public key, then the signature is valid; otherwise, the signature
fails.
In scenarios where it is necessary to minimize the time taken by the
public key generation process, a Hierarchical N-time Signature System
(HSS) can be used.
This hierarchical scheme, which we
describe in this section, uses the LMS scheme as a component.
In HSS, we have a sequence of L LMS trees, where the public key for the first LMS tree is included in the public key of the HSS system,
and where each LMS private key signs the next LMS public key, and where the last LMS private key signs the actual message.
For example, if we have a three level hierarchy (L=3), then to sign a message, we would have:
The first LMS private key (level 0) signs a level 1 LMS public key. The second LMS private key (level 1) signs a level 2 LMS public key. The third LMS private key (level 2) signs the message.
The root of the level 0 LMS tree is contained in the HSS public key.
To verify the LMS signature, we would verify all the signatures:
We would verify that the level 1 LMS public key is correctly signed by the level 0 signature.We would verify that the level 2 LMS public key is correctly signed by the level 1 signature.We would verify that the message is correctly signed by the level 2 signature.
We would accept the HSS signature only if all the signatures validated.
During the signature generation process, we sign messages with the lowest (level L-1) LMS tree.
Once we have used all the leafs in that tree to sign messages, we would discard it, generate a fresh LMS tree, and
sign it with the next (level L-2) LMS tree (and when that is used up, recursively generate and sign
a fresh level L-2 LMS tree).
HSS, in essence, utilizes a tree of LMS trees.
There is a single LMS tree at level 0 (the root).
Each LMS tree (actually, the private key corresponding to the LMS tree) at level i is used to sign 2^h objects (where h is the
height of trees at level i). If i < L-1, then each object will be
another LMS tree (actually, the public key) at level i+1; if i = L-1, we've reached the bottom of
the HSS tree, and so each object is a message from the application.
The HSS public
key contains the public key of the LMS tree at the root, and an HSS
signature is associated with a path from the root of the HSS tree to the leaf.
Compared to LMS, HSS has a much reduced public key
generation time, as only the root tree needs to be generated prior to the
distribution of the HSS public key.
For example, a L=3 tree (with h=10 at each level) would have 1 level 0 LMS tree,
2^10 level 1 LMS trees (with each such level 1 public key signed by one of the 1024
level 0 OTS public keys), and 2^20 level 2 LMS trees. Only 1024 OTS public
keys need to be computed to generate the HSS public key (as you need to compute
only the level 0 LMS tree to compute that value; you can, of course, decide to
compute the initial level 1 and level 2 LMS trees).
And, the 2^20 level 2 LMS trees can jointly sign a total of over a billion messages.
In contrast, a single LMS tree that could sign a billion messages would require a billion
OTS public keys to be computed first (even if h=30 were allowed in a supported
parameter set).
Each LMS tree within the hierarchy is associated with a distinct LMS public
key, private key, signature, and identifier. The number of levels
is denoted L, and is between one and eight, inclusive. The following
notation is used, where i is an integer between 0 and L-1 inclusive,
and the root of the hierarchy is level 0:
prv[i] is the current LMS private key of the i-th level.
pub[i] is the current LMS public key of the i-th level, as described in .
sig[i] is the LMS signature of public key pub[i+1] generated using the private key prv[i].
It is expected that the above arrays are maintained for the course of the HSS key.
The contents of the prv[] array MUST be kept private;
the pub[] and sig[] array may be revealed, should the implementation find that convienent.
In this section, we say that an N-time private key is exhausted when
it has generated N signatures, and thus it can no longer be used for
signing.
For i > 0, the values prv[i], pub[i] and (for all values of i) sig[i] will be updated over time,
as private keys are exhausted, and replaced by newer keys.
When these keys pairs are updated (or initially generated before the first message is signed),
then the LMS key generation processes outlined in sections and are performed.
If the generated key pairs are for level i of the HSS hierarchy, then we store the public
key in pub[i] and the private key in prv[i].
In addition, if i > 0, then we sign the generated public key with the LMS private key at level i-1,
placing the signature into sig[i-1].
When the LMS key pair are generated, the key pair and the corresponding identifier MUST be generated indepently of all other keypairs.
HSS allows L=1, in which case the HSS public key and signature formats
are essentially the LMS public key and signature formats, prepended
by a fixed field. Since HSS with L=1 has very little overhead
compared to LMS, all implementations MUST support HSS in order
to maximize interoperability.
We specifically allow different LMS levels to use different parameter sets.
For example, the 0-th LMS public key (the root) may use the LMS_SHA256_M32_H15 parameter set, while the 1-th public key may use LMS_SHA256_M32_H10.
There are practical reasons to allow this; for one, the signer may decide to store parts of the
0-th LMS tree (that it needs to construct while computing the public key) to accelerate later operations.
As the 0-th tree is never updated, these internal nodes will never need to be recomputed.
In addition, during the signature generation operation, almost all the operations involved with updating the
authentication path occurs with the bottom (L-1th) LMS public key; hence it may be useful to make the tree that implements that to be shorter.
A close reading of the HSS verification pseudocode would show that it would allow the parameters of the
non-top LMS public keys to change over time; for example, the signer might initially have the 1-th LMS public key to use LMS_SHA256_M32_H10,
but when that tree is exhausted, the signer might replace it with LMS_SHA256_M32_H15 LMS public key.
While this would work with the example verification pseudocode, the signer MUST NOT change the parameter sets for a specific level.
This prohibition is to support verifiers that may keep state over the course of several signature verifications.
The public key of the HSS scheme consists of the number of levels
L, followed by pub[0], the public key of the top level.
The HSS private key consists of prv[0], ... , prv[L-1], along with the
associated pub[0], ... pub[L-1] and sig[0], ..., sig[L-2] values.
As stated earlier, the values of the pub[] and sig[] arrays need not be
kept secret, but may be revealed.
The value
of pub[0] does not change (and, except for the index q, the value of
prv[0] need not change), though the values of pub[i] and
prv[i] are dynamic for i > 0, and are changed by the signature
generation algorithm.
During the key generation, the public and private keys are initialized.
Here is some pseudocode that explains the key generation logic
In the above algorithm, each LMS public/private keypair generated MUST be generated
indepedently.
Note that the value of the public key does not depend on the execution of step 2.
As a result, an implementation may decide to delay step 2
until later, for example, during the initial signature generation operation.
To sign a message using an HSS keypair, the following
steps are performed:
If prv[L-1] is exhausted, then determine the smallest integer d
such that all of the private keys prv[d], prv[d+1], ... , prv[L-1]
are exhausted. If d is equal to zero, then the HSS key pair is
exhausted, and it MUST NOT generate any more signatures.
Otherwise, the key pairs for levels d through L-1 must be
regenerated during the signature generation process, as follows.
For i from d to L-1, a new LMS public and private key pair with a
new identifier is generated, pub[i] and prv[i] are set to those
values, then the public key pub[i] is signed with prv[i-1], and
sig[i-1] is set to the resulting value.
The message is signed with prv[L-1], and the value sig[L-1] is set to
that result.
The value of the HSS signature is set as follows. We let
signed_pub_key denote an array of octet strings, where
signed_pub_key[i] = sig[i] || pub[i+1], for i between 0 and Nspk-1,
inclusive, where Nspk = L-1 denotes the number of
signed public keys. Then the HSS signature is u32str(Nspk) ||
signed_pub_key[0] || ... || signed_pub_key[Nspk-1] || sig[Nspk].
Note that the number of signed_pub_key elements in the signature
is indicated by the value Nspk that appears in the initial four
bytes of the signature.
Here is some pseudocode of the above logic
In the specific case of L=1, the format of an HSS signature is
In the general case, the format of an HSS signature is
which is equivalent to
To verify a signature S and message using the public key pub, the
following steps are performed:
Since the length of an LMS signature cannot be known without parsing
it, the HSS signature verification algorithm makes use of an LMS
signature parsing routine that takes as input a string consisting of
an LMS signature with an arbitrary string appended to it, and
returns both the LMS signature and the appended string. The
latter is passed on for further processing.
As for guidance as to the number of LMS level, and the size of each, any
discussion of performance is implementation specific. In general,
the sole drawback for a single LMS tree is the time it takes to generate the
public key; as every LM-OTS public key needs to be generated, the
time this takes can be substantial. For a two level tree, only the top level
LMS tree and the initial bottom level LMS tree needs to be generated initially
(before the first signature is generated); this will in general be significantly
quicker.
To give a general idea on the trade-offs available, we include some measurements
taken with the github.com/cisco/hash-sigs LMS implementation, taken on a 3.3 GHz Xeon processor,
with threading enabled.
We tried various parameter sets, all with W=8 (which minimizes signature size, while increasing time).
These are here to give a
guideline as to what's possible; for the computational time, your mileage
may vary, depending on the computing resources you have. The machine these tests were
performed on does not have the SHA-256 extensions; you could possibly do
significantly better.
ParmSetKeyGenTimeSigSizeKeyLifetime156 sec161630 seconds203 min177616 minutes251.5 hour19369 hours15/106 sec31729 hours15/156 sec333212 days20/103 min333212 days20/153 min34921 year25/101.5 hour34921 year25/151.5 hour365234 yearsParmSet: 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.
KeyGenTime: the measured key generation time; that is, the time needed to generate the public private key pair.
SigSize: the size of a signature (in bytes)
KeyLifetime: the lifetime of a key, assuming we generated 1000 signatures
per second. In practice, we're not likely to get anywhere close to
1000 signatures per second sustained; if you have a more appropriate
figure for your scenario, this column is pretty easy to recompute.
As for signature generation or verification times, those are moderately
insensitive to the above parameter settings (except for the Winternitz
setting, and the number of Merkle trees for verification). Tests on the same
machine (without multithreading) gave approximately 4msec to sign a short
message, 2.6msec to verify; these tests used a two
level ParmSet; a single level would approximately halve the verification
time. All times can be significantly improved (by perhaps a factor of 8) by
using a parameter set with W=4; however that also about doubles the
signature size.
The goal of this note is to describe the LM-OTS, LMS and HSS algorithms
following the original references and present the modern security
analysis of those algorithms. Other signature methods are out of
scope and may be interesting follow-on work.
We adopt the techniques described by Leighton and Micali to mitigate
attacks that amortize their work over multiple invocations of the
hash function.
The values taken by the identifier I across different LMS
public/private key pairs are chosen randomly in order to
improve security. The analysis of this method in
shows that we do not need uniqueness to ensure security; we do need to
ensure that we don't have a large number of private keys
that use the same I value. By randomly selecting 16 byte
I values, the chance that, out of 2^64 private keys,
4 or more of them will use the same I value is negligible
(that is, has probability less than 2^-128).
The reason 16 bytes I values were selected was to optimize the Winternitz hash chain operation.
With the current settings, the value being hashed is
exactly 55 bytes long
(for a 32 byte hash function),
which SHA-256 can hash in a single hash compression operation.
Other hash functions may be used in future
specifications; all the ones that we will be likely to support
(SHA-512/256 and the various SHA-3 hashes) would work well with a 16-byte I value.
The signature and public key formats are designed so that they are
relatively easy to parse. Each format starts with a 32-bit
enumeration value that indicates the details of the signature
algorithm and provides all of the information that is needed in order
to parse the format.
The Checksum is calculated using a
non-negative integer "sum", whose width was chosen to be an integer
number of w-bit fields such that it is capable of holding the
difference of the total possible number of applications of the
function H as defined in the signing algorithm of and the total actual number. In the
case that the number of times H is applied is 0,
the sum is (2^w - 1) * (8*n/w). Thus for the purposes of this
document, which describes signature methods based on H = SHA256 (n =
32 bytes) and w = { 1, 2, 4, 8 }, the sum variable is a 16-bit
non-negative integer for all combinations of n and w. The calculation
uses the parameter ls defined in and
calculated in , which indicates the
number of bits used in the left-shift operation.
To improve security against attacks that amortize their effort against
multiple invocations of the hash function, Leighton and Micali
introduce a "security string" that is distinct for each invocation of
that function. Whenever this process computes a hash, the string
being hashed will start with a string formed from the below fields.
These fields will appear in fixed locations in the value we compute
the hash of, and so we list where in the hash these fields would be present.
These fields that make up this string are:
I - a 16-byte identifier for the LMS public/private key pair. It
MUST be chosen uniformly at random, or via a pseudorandom process,
at the time that a key pair is generated, in order to minimize
the probability that any specific value of I be used for a
large number of different LMS private keys.
This is always bytes 0-15 of the value being hashed.
r - in the LMS N-time signature scheme, the node number r
associated with a particular node of a hash tree is used as an
input to the hash used to compute that node. This value is
represented as a 32-bit (four byte) unsigned integer in network
byte order. Either r or q (depending on the domain separation parameter) will be bytes 16-19 of the value being hashed.
q - in the LMS N-time signature scheme, each LM-OTS signature is
associated with the leaf of a hash tree, and q is set to the leaf
number. This ensures that a distinct value of q is used for each
distinct LM-OTS public/private key pair. This value is
represented as a 32-bit (four byte) unsigned integer in network
byte order. Either r or q (depending on the domain separation parameter) will be bytes 16-19 of the value being hashed.
D - a domain separation parameter, which is a two byte identifier that
takes on different values in the different contexts in which
the hash function is invoked. D occurs in bytes 20, 21 of the value being hashed and takes on the following values:
D_PBLC = 0x8080 when computing the hash of all of the
iterates in the LM-OTS algorithm
D_MESG = 0x8181 when computing the hash of the message in
the LM-OTS algorithms
D_LEAF = 0x8282 when computing the hash of the leaf of an LMS tree
D_INTR = 0x8383 when computing the hash of an interior node
of an LMS tree
i - a value between 0 and 264; this is used in the LM-OTS scheme, when either computing the
iterations of the Winternitz
chain, or when using the suggested LM-OTS private key generation process. It is represented as a
16-bit (two-byte) unsigned integer in network byte order.
If present, it occurs at bytes 20, 21 of the value being hashed.
j - in the LM-OTS scheme, j is the iteration
number used when the private key element is being iteratively
hashed. It is represented as an 8-bit (one byte) unsigned
integer and is present if i is a value between 0 and 264.
If present, it occurs at bytes 22 to 21+n of the value being hashed.
C - an n-byte randomizer that is included with the message whenever
it is being hashed to improve security. C MUST be chosen uniformly
at random, or via a pseudorandom process. It is present if D=D_MESG,
and it occurs at bytes 22 to 21+n of the value being hashed.
The Internet Assigned Numbers Authority (IANA) is requested to create
two registries: one for OTS signatures, which includes all of the
LM-OTS signatures as defined in , and one for Leighton-Micali
Signatures, as defined in .
Additions to these registries
require that a specification be documented in an RFC or another
permanent and readily available reference in sufficient detail that
interoperability between independent implementations is possible.
IANA SHOULD verify that all applications for additions to these
registries hve first been reviewed by the IRTF Crypto Forum Research Group (CFRG).
Each entry in the registry contains the following elements:
a short name, such as "LMS_SHA256_M32_H10", a positive number, anda reference to a specification that completely defines the
signature method test cases that can be used to verify the
correctness of an implementation.
The numbers between 0xDDDDDDDD (decimal 3,722,304,989) and
0xFFFFFFFF (decimal 4,294,967,295) inclusive, will not be
assigned by IANA, and are reserved for private use; no attempt
will be made to prevent multiple sites from using the same
value in different (and incompatible) ways
.
The LM-OTS registry is as follows.
NameReferenceNumeric Identifier Reserved 0x00000000 LMOTS_SHA256_N32_W1 0x00000001 LMOTS_SHA256_N32_W2 0x00000002 LMOTS_SHA256_N32_W4 0x00000003 LMOTS_SHA256_N32_W8 0x00000004
The LMS registry is as follows.
NameReferenceNumeric Identifier Reserved 0x0 - 0x4 LMS_SHA256_M32_H5 0x00000005 LMS_SHA256_M32_H10 0x00000006 LMS_SHA256_M32_H15 0x00000007 LMS_SHA256_M32_H20 0x00000008 LMS_SHA256_M32_H25 0x00000009
An IANA registration of a signature system does not constitute an
endorsement of that system or its security.
The LM-OTS and the LMS registries currently occupy a disjoint set of values.
This coincidence is a historical accident; the correctness of the system does not depend on this.
IANA is not required to maintain this situation.
The hash function H MUST have second preimage resistance: it must be
computationally infeasible for an attacker that is given one message M
to be able to find a second message M' such that H(M) = H(M').
The security goal of a signature system is to prevent forgeries. A
successful forgery occurs when an attacker who does not know the
private key associated with a public key can find a message (distinct
from all previously signed ones) and
signature that is valid with that public key (that is, the Signature
Verification algorithm applied to that signature and message and
public key will return VALID). Such an attacker, in the strongest
case, may have the ability to forge valid signatures for an arbitrary
number of other messages.
LMS is provably secure in the random oracle model, where the hash compression
function is considered the random oracle, as shown by . Corollary 1 of that paper states:
If we have no more than 2^64 randomly chosen LMS private keys, allow the
attacker access to a signing oracle and a SHA-256 hash compression oracle,
and allow a maximum of 2^120 hash compression computations, then the
probability of an attacker being able to generate a single forgery against
any of those LMS keys is less than 2^-129.
Many of the objects within the public key and the signature start with a typecode.
A verifier MUST check each of these typecodes, and a verification operation on a signature with
an unknown type, or a type that does not correspond to the type within
the public key MUST return INVALID. The expected length of a
variable-length object can be determined from its typecode, and if an
object has a different length, then any signature computed from the
object is INVALID.
The format of the inputs to the hash function H have the property that
each invocation of that function has an input that is repeated by a small bounded number of other inputs (due to potential repeats of the I value), and in particular, will vary
somewhere in the first 23 bytes of the value being hashed.
This property is important for a
proof of security in the random oracle model.
Each hash type listed is distinct; at locations 20, 21 of the value being
hashed, there exists either a fixed value D_PBLC, D_MESG, D_LEAF,
D_INTR, or a 16 bit value i. These fixed values are
distinct from each other, and are large (over 32768), while the 16 bit
values of i are small (currently no more than 265; possibly being slightly
larger if larger hash functions are supported); hence the range of possible values of i
will not collide any of the D_PBLC, D_MESG,
D_LEAF, D_INTR identifiers. The only other collision possibility is
the Winternitz chain hash colliding with the recommended pseudorandom
key generation process; here, at location 22 of the value being hashed, the Winternitz chain
function has the value u8str(j), where j is a value between 0 and
254, while location 22 of the recommended pseudorandom key generation
process has value 255.
For the Winternitz chaining function, D_PBLC, and D_MESG, the value of I || u32str(q) is
distinct for each LMS leaf (or equivalently, for each q value). For
the Winternitz chaining function, the value of u16str(i) || u8str(j) is distinct for each
invocation of H for a given leaf. For D_PBLC and D_MESG, the input
format is used only once for each value of q, and thus distinctness is
assured. The formats for D_INTR and D_LEAF are used exactly once for
each value of r, which ensures their distinctness. For the recommended
pseudorandom key generation process, for a
given value of I, q and j are distinct for each invocation of H.
The value of I is chosen uniformly at random from the set of
all 128 bit strings. If 2^64 public keys are generated (and hence 2^64 random I values),
there is a nontrivial probability of a duplicate (which would imply duplicate prefixes).
However, there will be an extremely high probability there will not be a four-way
collision (that is, any I value used for four distinct LMS keys; probability < 2^-132),
and hence the number of repeats for any specific
prefix will be limited to at most 3. This is shown (in ) to have only a limited effect on the
security of the system.
The LMS signature system, like all N-time signature systems,
requires that the signer maintain state across different invocations
of the signing algorithm, to ensure that none of the component
one-time signature systems are used more than once. This section
calls out some important practical considerations around this
statefulness.
These issues are discussed in greater detail in .
In a typical computing environment, a private key will be stored in
non-volatile media such as on a hard drive. Before it is used to
sign a message, it will be read into an application's Random Access
Memory (RAM). After a signature is generated, the value of the
private key will need to be updated by writing the new value of the
private key into non-volatile storage. It is essential for security
that the application ensure that this value is actually written into
that storage, yet there may be one or more memory caches between it
and the application. Memory caching is commonly done in the file
system, and in a physical memory unit on the hard disk that is
dedicated to that purpose. To ensure that the updated value is
written to physical media, the application may need to take several
special steps. In a POSIX environment, for instance, the O_SYNC flag
(for the open() system call) will cause invocations of the write()
system call to block the calling process until the data has been written to
the underlying hardware. However, if that hardware has its own
memory cache, it must be separately dealt with using an operating
system or device specific tool such as hdparm to flush the on-drive
cache, or turn off write caching for that drive. Because these
details vary across different operating systems and devices, this
note does not attempt to provide complete guidance; instead, we call
the implementer's attention to these issues.
When hierarchical signatures are used, an easy way to minimize the
private key synchronization issues is to have the private key for
the second level resident in RAM only, and never write that value
into non-volatile memory. A new second level public/private key
pair will be generated whenever the application (re)starts; thus,
failures such as a power outage or application crash are
automatically accommodated. Implementations SHOULD use this approach
wherever possible.
To show the security of LM-OTS checksum, we consider the signature y of
a message with a private key x and let h = H(message) and
c = Cksm(H(message)) (see ). To attempt
a forgery, an attacker may try to change the values of h and c. Let
h' and c' denote the values used in the forgery attempt. If for some integer j
in the range 0 to u, where u = ceil(8*n/w) is the size of the range that the checksum value can cover, inclusive,
a' = coef(h', j, w),
a = coef(h, j, w), and
a' > a
then the attacker can compute F^a'(x[j]) from F^a(x[j]) = y[j] by
iteratively applying function F to the j-th term of the signature an
additional (a' - a) times. However, as a result of the increased
number of hashing iterations, the checksum value c' will decrease
from its original value of c. Thus a valid signature's checksum will
have, for some number k in the range u to (p-1), inclusive,
b' = coef(c', k, w),
b = coef(c, k, w), and
b' < b
Due to the one-way property of F, the attacker cannot easily compute F^b'(x[k])
from F^b(x[k]) = y[k].
The eXtended Merkle Signature Scheme (XMSS) , is
similar to HSS in several ways. Both are stateful hash based
signature schemes, and both use a hierarchical approach, with a Merkle
tree at each level of the hierarchy. XMSS signatures are slightly
shorter than HSS signatures, for equivalent security and an equal
number of signatures.
HSS has several advantages over XMSS. HSS operations are roughly four
times faster than the comparable XMSS ones, when SHA256 is used as the
underlying hash. This occurs because the hash operation done as a part
of the Winternitz iterations dominates
performance, and XMSS performs four compression function invocations
(two for the PRF, two for the F function) where HSS needs only perform
one. Additionally, HSS is somewhat simpler (as each hash invocation is
just a prefix followed by the data being hashed).
Thanks are due to Chirag Shroff, Andreas Huelsing, Burt Kaliski, Eric
Osterweil, Ahmed Kosba, Russ Housley, Philip Lafrance,
Alexander Truskovsky, Mark Peruzel for
constructive suggestions and valuable detailed review. We especially
acknowledge Jerry Solinas, Laurie Law, and Kevin Igoe, who pointed out
the security benefits of the approach of Leighton and Micali and Jonathan Katz, who gave us security
guidance, and Bruno Couillard and Jim Goodman for an especially thorough review.
&rfc2119;
&rfc2434;
&rfc3979;
&rfc4506;
&rfc4879;
Secure Hash Standard (SHS)National Institute of Standards and TechnologyLarge provably fast and secure digital signature schemes from secure hash functionsAnalysis of a proposed hash-based signature standardFurther analysis of a proposed hash-based signature standardXMSS-a practical forward secure signature scheme based on minimal security assumptions.
&rfc8391;
State Management for Hash-based Signatures.A fast quantum mechanical algorithm for database searchA Certified Digital SignatureOne Way Hash Functions and DESA Digital Signature Based on a Conventional Encryption FunctionSecrecy, Authentication, and Public Key Systems
An implementation MAY use the following pseudorandom process
for generating an LMS private key.
SEED is an m-byte value that is generated uniformly
at random at the start of the process,
I is LMS key pair identifier,
q denotes the LMS leaf number of an LM-OTS private key,
x_q denotes the x array of private elements in the LM-OTS private
key with leaf number q,
i is the index of the private key element, and
H is the hash function used in LM-OTS.
The elements of the LM-OTS private keys are computed as:
This process stretches the m-byte random value SEED into a (much
larger) set of pseudorandom values, using a unique counter in each
invocation of H. The format of the inputs to H are chosen so that
they are distinct from all other uses of H in LMS and LM-OTS.
A careful reader will note that this is similar to the hash we
perform when iterating through the Winternitz chain; however in
that chain, the iteration index will vary between 0 and 254 maximum
(for W=8), while the corresponding value in this formula is 255.
This algorithm is included in the proof of security in
and hence this method is safe
when used within the LMS system; however any other cryptographical
secure method of generating private keys would also be safe.
The LM-OTS one time signature method uses several internal parameters, which are a function of the selected parameter set.
These internal parameters set:
p - This is the number of independent Winternitz chains used in the signature;
it will be the number of w-bit digits needed to hold the n-bit hash (u in the below equations),
along with the number of digits needed to hold the checksum (v in the below equations) ls - This is the size of the shift needed to move the checksum so that it appears in the checksum digits
ls is needed because, while we express the checksum internally as a 16 bit value, we don't always express all 16 bits
in the signature; for example, if w=4, we might use only the top 12 bits.
Because we read the checksum in network order, this means that, without the shift, we'll use the higher order bits (which may
be always 0), and omit the lower order bits (where the checksum value actually resides).
This shift is here to ensure that the parts of the
checksum we need to express (for security) actually contribute to the signature; when multiple such shifts are possible,
we take the minimal value.
A table illustrating various combinations of n and w with the associated values of
u, v, ls, and p is provided in
.
Hash Length in Bytes (n)Winternitz Parameter (w)w-bit Elements in Hash (u)w-bit Elements in Checksum (v)Left Shift (ls)Total Number of w-bit Elements (p)3212569726532212856133324643467328322034
The LMS public key can be computed using the following algorithm or
any equivalent method. The algorithm uses a stack of hashes for data. It also makes use of a hash function with the typical
init/update/final interface to hash functions; the result of the
invocations hash_init(), hash_update(N[1]), hash_update(N[2]), ... ,
hash_update(N[n]), v = hash_final(), in that order, is identical to
that of the invocation of H(N[1] || N[2] || ... || N[n]).
The LMS signature consists of u32str(q) || lmots_signature || u32str(type) || path[0] || path[1] || ... || path[h-1].
This appendix shows one method of constructing this signature, assuming that the implementation has stored the
T[] array that was used to construct the public key. Note that this is not the only possible method; other
methods exist which don't assume that you have the entire T[] array in memory.
To construct a signature, you perform the following algorithm:
where 'xor' is the bitwise exclusive-or operation, and / is integer division (that is, rounded down to an integer value)
An example implementation can be found online at https://github.com/cisco/hash-sigs.
This section provides test cases that can be used to verify or debug
an implementation. 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.