]>
Hash-Based SignaturesCisco Systems13600 Dulles Technology DriveHerndon20171VAUSAmcgrew@cisco.comCisco Systems7025-2 Kit Creek RoadResearch Triangle Park27709-4987NCUSAmicurcio@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. It specifies a one-time signature scheme based on the
work of Lamport, Diffie, Winternitz, and Merkle (LDWM), and a
general signature scheme, Merkle Tree Signatures (MTS). 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.
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 development 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 relatively slow key generation. In recent years there
has been interest in these systems because of their post-quantum
security (see ) and their suitability for compact
implementations.
This note describes the original Lamport-Diffie-Winternitz-Merkle
(LDWM) one-time signature system (following Merkle 1979 but also using
a technique from Merkle's later work ) and Merkle tree
signature system (following Merkle 1979) 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 exactly one message
securely. A general signature system can be used to sign multiple
messages. The Merkle Tree Signatures (MTS) is a general signature
system that uses an OTS system as a component. In principle the MTS
can be used with any OTS system, but in this note we describe its use
with the LDWM system.
This note is structured as follows. Notation is introduced in
. The LDWM signature system is described in
, and the Merkle tree signature system is
described in . Sufficient detail is
provided to ensure interoperability.
describes test considerations and contains test cases that can be used
to validate an implementation. The IANA registry for these signature
systems is described in . Security
considerations are presented in .
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 .
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.
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+ : a + b denotes the sum of a and b- : a - b denotes the difference of a and b
The standard order of operations is used when evaluating arithmetic expressions.
If A and B are bytes, then A AND B denotes the bitwise logical and
operation.
When B is a byte and i is an integer, then B >> i denotes the logical
right-shift operation.
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.
The i^th byte string in an array A is denoted as A[i].
If S is a byte string, then byte(S, i) denotes its i^th byte, where
byte(S, 0) is the leftmost byte. 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 should raise an error.
If r is a non-negative real number, then we define the following functions:
ceil(r) : returns the smallest integer larger than rfloor(r) : returns the largest integer smaller than rlg(r) : returns the base-2 logarithm of r
When F is a function that takes r-byte strings as input and returns
r-byte strings as output, we denote the repeated applications of F
with itself a non-negative, integral number of times i as F^i.
This section defines LDWM 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 only one time to sign any given message.
As part of the signing process, a digest of the original message is
computed using the collision-resistant hash function H (see ), and the resulting digest is signed.
The signature system uses the parameters m, n, and w; they are all
positive integers. The algorithm description also uses the values p
and ls. These parameters are summarized as follows:
m : the length in bytes of each element of an LDWM signaturen : the length in bytes of the result of the hash functionw : the Winternitz parameter; it is a member of the set { 1, 2, 4, 8 }p : the number of m-byte string elements that make up the LDWM signature
ls : the number of left-shift bits used in the checksum function C (defined in ).
The values of m and n are determined by the functions selected for use as part of
the LDWM algorithm. They are chosen to ensure an appropriate level of
security. The parameter w can be chosen to set the number of bytes in the signature;
it has little effect on security. Note however, that there is a
larger computational cost to generate and verify a shorter 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 is provided in .
The LDWM algorithm uses a collision-resistant hash function H and a
one way (preimage resistant) function F. H accepts byte strings of
any length, and returns an n-byte string. F has m-byte inputs and
m-byte outputs.
To fully describe a LDWM signature method, the parameters m, n, and w,
as well as the functions H and F MUST be specified. This section defines
several LDWM signature systems, each of which is identified by a name.
Values for p and ls are provided as a convenience.
NameHFmnwplsLDWM_SHA512_M64_W1SHA512SHA512323212657LDWM_SHA512_M64_W2SHA512SHA512323221336LDWM_SHA512_M64_W4SHA512SHA51232324674LDWM_SHA512_M64_W8SHA512SHA51232328340LDWM_SHA256_M32_W1SHA256SHA256323212657LDWM_SHA256_M32_W2SHA256SHA256323221336LDWM_SHA256_M32_W4SHA256SHA25632324674LDWM_SHA256_M32_W8SHA256SHA25632328340LDWM_SHA256_M20_W1SHA256SHA256-20203212657LDWM_SHA256_M20_W2SHA256SHA256-20203221336LDWM_SHA256_M20_W4SHA256SHA256-2020324674LDWM_SHA256_M20_W8SHA256SHA256-2020328340
Here SHA512 and SHA256 denotes the NIST standard hash functions . SHA256-20 denotes the SHA256 hash function with
its final output truncated to return the leftmost 20 bytes.
The LDWM private key is an array of size p containing m-byte
strings. Let x denote the private key. This private key must be used
to sign one and only one message. It must therefore be unique from
all other private keys. The following algorithm shows pseudocode for
generating x.
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 LDWM algorithm.
The LDWM public key is generated from the private key
by applying the function F^(2^w - 1) to each
individual element of x, then hashing all of the resulting
values.
The following algorithm shows pseudocode for
generating the public key, where the array x is the private key.
A checksum is used to ensure that any forgery attempt that manipulates
the elements of an existing signature will be detected. The security
property that it provides is detailed in .
The checksum value is calculated using a non-negative integer, sum,
whose width is sized 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 F as defined in the signing algorithm of
and the total actual number. In the
worst case (i.e. the actual number of times F is iteratively applied
is 0), the sum is (2^w - 1) * ceil(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 }, let sum be 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.
The checksum function C is defined as follows, where S denotes
the byte string that is input to that function.
Implementation Note: Based on the previous fact, an implementation
MAY choose to optimize the width of sum to (v * w) bits and
set ls to 0. The rationale for this is given that (2^w - 1) *
ceil(8*n/w) is the maximum value of sum and the value of (2^w - 1) is
represented by w bits, the result of adding u w-bit numbers, where u =
ceil(8*n/w), requires at most (ceil(lg(u)) + w) bits. Dividing by w
and taking the next largest integer gives the total required number of
w-bit fields and gives (ceil(lg(u)) / w) + 1, or v. Thus sum requires
a minimum width of (v * w) bits and no left-shift operation is
performed.
The LDWM signature is generated by using H to compute the hash of the
message, concatenating the checksum of the hash to the hash itself,
then considering the resulting value as a sequence of w-bit values,
and using using each of the the w-bit values to determine the number
of times to apply the function F to the corresponding element of the
private key. The outputs of the function F are concatenated together
and returned as the signature. The pseudocode for this procedure is
shown below.
The signature should be provided by the signer to the verifier, along
with the message and the public key.
In order to verify a message with its signature (an array of m-byte
strings, denoted as y), the receiver must "complete" the series of
applications of F, using the w-bit values of the message hash and its
checksum. This computation should result in a value that matches the
provided public key.
A future version of this specification may
define a method for computing the signature
of a very short message in which the hash
is not applied to the message during
the signature computation. That
would allow the signatures to have reduced size.
Though the data formats are formally defined by XDR, we diagram the
format as well as a convenience to the reader. An example of the
format of an ldwm_signature is illustrated below, for
ldwm_sha256_m32_w1. An ots_signature consists of a 32-bit unsigned
integer that indicates the ots_algorithm_type, followed by other data,
whose format depends only on the ots_algorithm_type. In the case of
LDWM, the data is an array of equal-length byte strings. The number
of bytes in each byte string, and the number of elements in the array,
are determined by the ots_algorithm_type field. In the case of
ldwm_sha256_m32_w1, the array has 265 elements, each of which is a
32-byte string. The XDR array y_m32_p265 denotes the array y as used
in the algorithm descriptions above, using the parameters of m=32 and
p=265 for ldwm_sha256_m32_w1.
A verifier MUST check the ots_algorithm_type field, and a
verification operation on a signature with an unknown
ldwm_algorithm_type MUST return FAIL.
Merkle Tree Signatures (MTS) are a method for signing a potentially
large but fixed number of messages. An MTS system uses two
cryptographic components: a one-time signature method and a
collision-resistant hash function. Each MTS public/private key pair
is associated with a perfect k-ary tree, each node of which contains
an n-byte value. Each leaf of the tree contains the value of the
public key of an LDWM public/private key pair. The value contained by
the root of the tree is the MTS public key. Each interior node is
computed by applying the hash function to the concatenation of the
values of its children nodes.
An MTS system has the following parameters:
k : the number of children nodes of an interior node,
h : the height (number of levels - 1) in the tree, and
n : the number of bytes associated with each node.
There are k^h leaves in the tree.
An MTS private key consists of k^h one-time signature private keys
and the leaf number of the next LDWM private key that has not yet
been used. The leaf number is initialized to zero when the MTS
private key is created.
An MTS private key MAY be generated pseudorandomly from a secret
value, in which case the secret value MUST be at least n bytes long, be
uniformly random, and MUST NOT be used for any other purpose than
the generation of the MTS 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.
An MTS public key is defined as follows,
where we denote the public key associated with the
i^th LDWM private key as ldwm_public_key(i).
The MTS public key can be computed using the following
algorithm or any equivalent method. The algorithm uses
a stack of hashes for data and a separate stack of integers
to keep track of the level of the Merkle tree.
An MTS signature consists of
an LDWM signature,
a node number that identifies the leaf node associated with the signature, and
an array of values that is associated with the path through the
tree from the leaf associated with the LDWM signature to the
root.
The array of values contains contains the siblings of the nodes on the
path from the leaf to the root but does not contain the nodes on the
path itself. The array for a tree with branching number k and height
h will have (k-1)*h values. The first (k-1) values are the siblings
of the leaf, the next (k-1) values are the siblings of the parent of
the leaf, and so on.
To compute the MTS signature of a message with an MTS private key,
the signer first computes the LDWM signature of the message
using the leaf number of the next unused LDWM private key.
Before releasing the signature, the leaf number in the
MTS private key MUST be incremented to prevent the LDWM private key
from being used again.
The node number in the signature is set to the leaf
number of the MTS private key that was used in the signature.
The array of node values MAY be computed in any way. There are
many potential time/storage tradeoffs. The fastest alternative is
to store all of the nodes of the tree and set the array in the
signature by copying them. 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.
An MTS signature is verified by first using the LDWM signature
verification algorithm to compute the LDWM public key from the LDWM
signature and the message. The value of the leaf associated with the
LDWM signature is assigned to the public key.
Then the root of the tree is computed from the leaf value
and the node array (path[]) as described below. If the root
value matches the public key, then the signature is valid;
otherwise, the signature fails.
This algorithm uses 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]).
This algorithm works because the leaves of the MTS tree are numbered
starting at zero. Therefore leaf n is in the position (n % k) in the
highest level of the tree.
The verifier MAY cache interior node values that have been computed
during a successful signature verification for use in
subsequent signature verifications. However, any implementation
that does so MUST make sure any nodes that are cached during
a signature verification process are deleted if that
process does not result in a successful match between
the root of the tree and the MTS public key.
A full test example that combines the LDWM OTS and MTS algorithms is given in
.
The goal of this note is to describe the LDWM and MTS 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.
The signature and public key formats are designed so that they are
easy to parse. Each format starts with a 32-bit enumeration value
that indicates all of the details of the signature algorithm and
hence defines all of the information that is needed in order to parse the
format.
The enumeration values used in this note are palindromes, which have
the same byte representation in either host order or network order.
This fact allows an implementation to omit the conversion between
byte order for those enumerations. Note however that the leaf
number field used in the MTS signature and keys must be properly
converted to and from network byte order; this is the only field
that requires such conversion. There are 2^32 XDR enumeration
values, 2^16 of which are palindromes, which is more than enough for
the foreseeable future. If there is a need for more assignments,
non-palindromes can be assigned.
This is the initial version of this draft.
This section is to be removed by the RFC editor upon publication.
The Internet Assigned Numbers Authority (IANA) is requested to create
two registries: one for OTS signatures, which includes all of the LDWM
signatures as defined in Section 3, and one for Merkle Tree
Signatures, as defined in Section 4. 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.
Each entry in the registry contains the following elements:
a short name, such as "MTS_SHA256_K16_H5", 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.
Requests to add an entry to the registry MUST include the name and the
reference. The number is assigned by IANA. These number assignments
SHOULD use the smallest available palindromic number. Submitters
SHOULD have their requests reviewed by the IRTF Crypto Forum Research
Group (CFRG) at cfrg@ietf.org. Interested applicants that are
unfamiliar with IANA processes should visit http://www.iana.org.
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 LDWM registry is as follows.
NameReferenceNumeric Identifier LDWM_SHA256_M20_W1 0x01000001 LDWM_SHA256_M20_W2 0x02000002 LDWM_SHA256_M20_W4 0x03000003 LDWM_SHA256_M20_W8 0x04000004 LDWM_SHA256_M32_W1 0x05000005 LDWM_SHA256_M32_W2 0x06000006 LDWM_SHA256_M32_W4 0x07000007 LDWM_SHA256_M32_W8 0x08000008 LDWM_SHA512_M64_W1 0x09000009 LDWM_SHA512_M64_W2 0x0a00000a LDWM_SHA512_M64_W4 0x0b00000b LDWM_SHA512_M64_W8 0x0c00000c
The MTS registry is as follows.
NameReferenceNumeric Identifier MTS_SHA256_K2_H20 0x01000001 MTS_SHA256_K4_H10 0x02000002 MTS_SHA256_K8_H7 0x03000003 MTS_SHA256_K16_H5 0x04000004 MTS_SHA512_K2_H20 0x05000005 MTS_SHA512_K4_H10 0x06000006 MTS_SHA512_K8_H7 0x07000007 MTS_SHA512_K16_H5 0x08000008
An IANA registration of a signature system does not constitute an
endorsement of that system or its security.
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 and
signature that are 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.
The security of the algorithms defined in this note can be roughly
described as follows. For a security level of roughly 128 bits,
assuming that there are no quantum computers, use the LDWM algorithms
with m=32 and MTS with n=32. For a security level of roughly 128
bits, assuming that there are quantum computers, use the LDWM
algorithms with m=64 and the MTS algorithms with n=64. For the
smallest possible signatures that provide a currently adequate
security level, use the LDWM algorithms with m=20 and MTS algorithms
with n=32. We emphasize that this is a rough estimate, and not
a security proof.
LDWM signatures rely on the fact that, given an m-byte string y, it is
prohibitively expensive to compute a value x such that F^i(x) = y for
any i. Informally, F is said to be a "one-way" function, or a
preimage-resistant function. Both LDWM and MTS signatures rely on the
fact that H is collision-resistant, that is, it is prohibitively
expensive for an attacker to find two byte strings a and b such that
H(a) = H(b).
There are several formal security proofs for one time signatures and
Merkle tree signatures in the cryptographic literature. Several of
these analyze variants of those algorithms, and are not directly
applicable to the original algorithms; thus caution is needed when
applying these analyses. The MTS scheme has been shown to provide
roughly b bits of security when used with a hash function with an
output size of 2*b bits . (A cryptographic
scheme has b bits of security when an attacker must perform O(2^b)
computations to defeat it.) More precisely, that analysis shows that
MTS is existentially unforgeable under an adaptive chosen message
attack. However, the analysis assumes that the hash function is
chosen uniformly at random from a family of hash functions, and thus
is not completely applicable. Similarly, LDWM with w=1 has been shown
to be existentially unforgeable under an adaptive chosen message
attack, when F is a one-way function , when F is
chosen uniformly at random from a family of one-way functions; when F
has c-bit inputs and outputs, it provides roughly b bits of security.
LDWM signatures, as specified in this note, have been shown to be
secure based on the collision resistance of F ; that analysis provides a lower bound on security
(and it appears to be pessimistic, especially in the case of the m=20
signatures).
It may be desirable to adapt this specification in a way that better
aligns with the security proofs. In particular, a random "salt" value
could be generated along with the key, used as an additional input to
F and H, and then provided as part of the public key. This change
appears to make the analysis of applicable, and
it would improve the resistance of these signature schemes against key
collision attacks, that is, scenarios in which an attacker
concurrently attacks many signatures made with many private keys.
To show the security of LDWM checksum, we consider the signature y of
a message with a private key x and let h = H(message) and
c = C(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-1), 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].
LDWM and MTS signatures rely on a minimum of security conjectures. In
particular, their security does not rely on the computational
difficulty of factoring composites with large prime factors (as does
RSA) or the difficulty of computing the discrete logarithm in a finite
field (as does DSA) or an elliptic curve group (as does ECDSA). All
of these signature schemes also rely on the security of the hash
function that they use, but with LDWM and MTS, the security of the
hash function is sufficient.
A post-quantum cryptosystem is a system that is secure against quantum
computers that have more than a trivial number of quantum bits. It is
open to conjecture whether or not it is feasible to build such
a machine.
The LDWM and Merkle signature systems are post-quantum secure if they
are used with an appropriate underlying hash function, in which the
size of m and n are double what they would be otherwise, in order to
protect against quantum square root attacks due to Grover's algorithm.
In contrast, the signature systems in wide use (RSA, DSA, and ECDSA)
are not post-quantum secure.
Thanks are due to Chirag Shroff for constructive feedback, and to
Andreas Hulsing, Burt Kaliski, Eric Osterweil, Ahmed Kosba, and Russ
Housley for valuable detailed review.
&rfc2119;
&rfc2434;
&rfc4506;
Secure Hash Standard (SHS)National Institute of Standards and Technology
Hash-based Digital Signature Schemes
Hash Based Digital Signature SchemesA Certified Digital SignatureOne Way Hash Functions and DESA Digital Signature Based on a Conventional Encryption FunctionSecrecy, Authentication, and Public Key Systems
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)20116088168202804884204403443208202022321256972653221285613332464346732832203448138497393482192561974849634994884820506415121065226422565626164412834131648642066
As with all cryptosystems, implementations of LDWM signatures and
Merkle signatures need to be tested before they are used. This section contains
sample data generated from the signing and verification operations of software
that implements the algorithms described in this document.
The example contained in this section demonstrates the calculations of LDWM_SHA256_M20_W4
using a Merkle Tree Signature of degree 4 and height 2. This corresponds to the following
parameter values:
mnwplskh2032467442
The non-standard size of the Merkle tree (h = 2) has been selected specifically
for this example to reduce the amount of data presented.
The LDWM algorithm does not define a required method of key
generation. This is left to the implementer. The selected method,
however, must satisfy the requirement that the private keys of the
one-time signatures are uniformly random, independent, and
unpredicable. In addition, all LDWM key pairs must be generated in
advance in order to calculate the value of the Merkle public key.
For the test data presented here, a summary of the key generation method is as follows:
MTS Private Key - Set mts_private_key to a pseudorandomly generated n-byte value.OTS Private Keys - Use the mts_private_key as a key derivation key input to some key
derivation function, thereby producing n^k derived keys. Then use each derived key as an
input to the same function again to further derive p elements of n-bytes each.
This accomplishes the result of Algorithm 0 of for each
leaf of the Merkle tree.OTS Public Keys - For each OTS private key, calculate the corresponding OTS public key
as in Algorithm 1 of .MTS Public Key - Each OTS public key is the value of a leaf on the
Merkle tree. Calculate the MTS public key using the pseudocode
algorithm of or some equivalent implementation.
The above steps result in the following data values associated with the first leaf of the
Merkle tree, leaf 0.
MTS Private Key0x0f677ff1b4cbf10baec89959f051f203 3371492da02f62dd61d6fbd1cee1bd14Key Element Index (i)OTS Private Key 0 Element (x[i])00xbfb757383fb08d324629115a84daf00b 188d5695303c83c184e1ec7a501c431f10x7ce628fb82003a2829aab708432787d0 fc735a29d671c7d790068b453dc8c91320x8174929461329d15068a4645a34412bd 446d4c9e757463a7d5164efd50e05c9330xf283f3480df668de4daa74bb0e4c5531 5bc00f7d008bb6311e59a5bbca910fd740xe62708eaf9c13801622563780302a068 0ba9d39c078daa5ebc3160e1d80a1ea750x1f002efad2bfb4275e376af7138129e3 3e88cf7512ec1dcdc7df8d5270bc0fd760x8ed5a703e9200658d18bc4c05dd0ca8a 356448a26f3f4fe4e0418b52bd6750a270xc74e56d61450c5387e86ddad5a8121c8 8b1bc463e64f248a1f1d91d95095772680x629f18b6a2a4ea65fff4cf758b57333f e1d34af05b1cd7763696899c9869595f90x1741c31fdbb4864712f6b17fadc05d45 926c831c7a755b7d7af57ac316ba6c2a100xe59a7b81490c5d1333a9cdd48b9cb364 56821517a3a13cb7a8ed381d4d5f3545110x3ba97fe8b2967dd74c8b10f31fc5f527 a23b89c1266202a4d7c281e1f41fa020120xa262a9287cc979aaa59225d75df51b82 57b92e780d1ab14c4ac3ecdac58f1280130x9dfe0af1a3d9064338d96cb8eae88baa 6a69265538873b4c17265fa9d573bcff140xde9c5c6a5c6a274eabe90ed2a8e6148c 720196d237a839aaf5868af8da4d0829150x5de81ec17090a82cb722f616362d3808 30f04841191e44f1f81b9880164b14cd160xc0d047000604105bad657d9fa2f9ef10 1cfd9490f4668b700d738f2fa9e1d11a170xf45297ef310941e1e855f97968129bb1 73379193919f7b0fee9c037ae507c2d2180x46ef43a877f023e5e66bbcd4f06b839f 3bfb2b64de25cd67d1946b0711989129190x46e2a599861bd9e8722ad1b55b8f0139 305fcf8b6077d545d4488c4bcb652f29200xe1ad4d2d296971e4b0b7a57de305779e 82319587b58d3ef4daeb08f630bd5684210x7a07fa7aed97cb54ae420a0e6a58a153 38110f7743cab8353371f8ca710a4409220x40601f6c4b35362dd4948d5687b5cb6b 5ec8b2ec59c2f06fd50f8919ebeaae92230xa061b0ba9f493c4991be5cd3a9d15360 a9eb94f6f7adc28dddf174074f3df3c4240xcf1546a814ff16099cebf1fe0db1ace5 1c272fda9846fbb535815924b0077fa4250xcbb06f13155ce4e56c85a32661c90142 8b630a4c37ea5c7062156f07f6b3efff260x1181ee7fc03342415094e36191eb450a 11cdea9c6f6cdc34de79cee0ba5bf230270xe9f1d429b343bb897881d2a19ef363cd 1ab4117cbaad54dc292b74b8af9f5cf2280x87f34b2551ef542f579fa65535c5036f 80eb83be4c898266ffc531da2e1a9122290x9b4b467852fe33a03a872572707342fd ddeae64841225186babf353fa2a0cd09300x19d58cd240ab5c80be6ddf5f60d18159 2dca2be40118c1fdd46e0f14dffbcc7d310x5c9ad386547ba82939e49c9c74a8eccf 1cea60aa327b5d2d0a66b1ca48912d6d320xf49083e502400ffae9273c6de92a301e 7bda1537cab085e5adfa9eb746e8eca9330x4074e1812d69543ce3c1ce706f6e0b45 f5f26f4ef39b34caa709335fd71e8fc0340x1256612b0ca8398e97b247ae564b74b1 3839b3b1cf0a0dd8ba629a2c58355f84350xbab3989f00fd2c327bbfb35a218cc3ce 49d6b34cbf8b6e8919e90c4eff400ca9360x96b52a5d395a5615b73dae65586ac5c8 7f9dd3b9b3f82dbf509b5881f0643fa8370x5d05ca4c644e1c41ccdaedbd2415d4f0 9b4a1b940b51fe823dff7617b8ee8304380xd96aab95ef6248e235d91d0f23b64727 a6675adfc64efea72f6f8b4a47996c0d390xfd9c384d52d3ac27c4f4898fcc15e83a c182f97ea63f7d489283e2cc7e6ed180400xc86eaed6a9e3fbe5b262c1fa1f099f7c 35ece71d9e467fab7a371dbcf400b544410xf462b3719a2ed8778155638ff814dbf4 2b107bb5246ee3dd82abf97787e6a69e420x014670912e3eb74936ebb64168b447e4 2522b57c2540ac4b49b9ae356c01eca6430x2b411096e0ca16587830d3acd673e858 863fedc4cea046587cba0556d2bf9884440xa73917c74730582e8e1815b8a07b1896 2ac05e500e045676be3f1495fcfa18ca450xa4ab61e6962fe39a255dbf8a46d25110 0d127fab08db59512653607bda24302c460x9b910ca516413f376b9eba4b0d571b22 253c2a9646131ac9a2af5f615f7322b8470xfc1b4ce627c77ad35a21ea9ded2cce91 b3758a758224e35cf2918153a513d64c480xc1902d8e8c02d9442581d7e053a2798a a84d77a74b6e7f2cc5096d50646c890f490xb3f47e2e8e2dcdd890ea00934b9d8234 830dbc4a30ac996b144f12b3e463c77f500x8188d1ecfc6ae6118911f2b9b3a6c7a1 e5f909aa8b5c0aab8c69f1a7d436c307510xca42d985974c7b870bc76494604eff49 2676c942c6cb7c75d4938805885dd054520xbe58851ebe566057e1ee16b8c604a473 4c373af622660b2a82357ac6effb4566530xc22d493f7a5642fceba2404dbefa8f95 6323fac87fac425f6de8d23c9e8b20ca540x1a76c1ffa467906173fd0245b0cd6639 e6013ca79c4ed92426ee69ff5beeac0b550xbc6c0cb7808f379af1b7b7327436ad65 c05458f2d0a6923c333e5129c4c99671560xfbb04488c3c088dc5e63d13e6a701036 6109ca4c5f4b0a8d37780187e2e9930e570xaec10811569d4d72e3a1baf71a886b75 eba6dc07ed027af0b2beffa71f9b43c8580xf5529be3b7a19212e8baa970d2420bf4 123f678267f96c1c3ef26ab610cb0061590x172ba1ba0b701eeafe00692d1eb90181 8ccaefaeb8f799395da81711766d1f43600xfe1f8c15825208f3a21346b894b3d94e 4f3aa29cbc194a7b2c8a810c4c509042610x2e81c66cc914ea1b0fa5942fe9780d54 8c0b330e3bf73f0cb0bda4bc9c9e6ff4620xfc3453aec5cc19a6a4bda4bc25931604 704bf4386cd65780c6e73214c1da85ba630x4e8000c587dc917888e7e3d817672c0a ef812788cc8579afa7e9b2e566309003640xba667ca0e44a8601a0fde825d4d2cf1b b9cf467041e04af84c9d0cd9fd8dc784650x4965db75f81c8a596680753ce70a94c6 156253bb426947de1d7662dd7e05e9a8660x2c23cc3e5ca37dec279c506101a3d8d9 f1e4f99b2a33741b59f8bddba7455419
Using the value of the OTS private key above, the corresponding public key is given below.
Intermediate values of the SHA256-20 function F^(2^w - 1)(x[i]) are provided in
.
OTS Public Key 00x2db55a72075fcfab5aedbef77bf6b371 dfb489d6e61ad2884a248345e6910618
Following the creation of all OTS public/private key pairs, the OTS public keys in
are used to determine the MTS public key below. Intermediate
values of the interior nodes of the Merkle tree are provided in .
MTS Public Key0x6610803d9a3546fb0a7895f6a4a0cfed 3a07d45e51d096e204b018e677453235
In order to test signature generation, a text file containing the content "Hello world!\n",
where '\n' represents the ASCII line feed character, was created and signed. A raw hex dump
of the file contents is shown in the table below.
Hexadecimal Byte ValuesASCII Representation ('.' is substituted for non-printing characters)0x48 0x65 0x6c 0x6c 0x6f 0x20 0x77 0x6f 0x72 0x6c 0x64 0x21 0x0aHello world!.
The SHA256 hash of the text file is provided below.
SHA256 Hash of Signed File (H("Hello world!\n"))0x0ba904eae8773b70c75333db4de2f3ac 45a8ad4ddba1b242f0b3cfc199391dd8
This value was subsequently used in Algorithm 3 of to
create the one-time signature of the message. Algorithm 2 of
was applied to calculate a checksum of 0x1cc. The
resulting signature is shown in the following table.
OTS Element Index (i)Function Iteration Count (a = coef( H(msg) || C(H(msg)), i, w ))OTS Element (y[i] = F^a(x[i]))000xbfb757383fb08d324629115a84daf00b188d56951110x4af079e885ddfd3245f29778d265e868a3bfeaa42100xfbad1928bfc57b22bcd949192452293d07d6b9ad390xb98063e184b4cb949a51e1bb76d99d4249c0b448400xe62708eaf9c13801622563780302a0680ba9d39c540x39343cba3ffa6d75074ce89831b3f3436108318c6140xfe08aa73607aec5664188a9dacdc34a295588c9a7100xd3346382119552d1ceb92a78597a00c956372bf08140xf1dd245ec587c0a7a1b754cc327b27c839a6e46a980xa5f158adc1decaf0c1edc1a3a5d8958d726627b51070x06d2990f62f22f0c943a418473678e3ffdbff4821170xf3390b8d6e5229ae9c5d4c3f45e10455d8241a491230x22dd5f9d3c89180caa0f695203d8cf90f3c359be13110x67999c4043f95de5f07d82b741347a3eb6ac0c251470xc4ffe472d48adeb37c7360da70711462013b7a4e1500x5de81ec17090a82cb722f616362d380830f0484116120x2f892c824af65cc749f912a36dfa8ade2e4c3fd11770xb644393e8030924403b594fb5cacd8b2d28862e21850x31b8d2908911dbbf5ba1f479a854808945d9e9481930xa9a02269d24eb8fed6fb86101cbd0d8977219fb12030xe4aae6e6a9fe1b0d5099513f170c111dee95714d2130xd79c16e7f2d4dd790e28bab0d562298c864e31e922130xc29678f0bb4744597e04156f532646c98a0b42e823110x57b31d75743ff0f9bcf2db39d9b6224110b8d27b2440x0a336d93aac081a2d849c612368b8cbb2fa9563a25130x917be0c94770a7bb12713a4bae801fb3c1c4300226140x91586feaadcf691b6cb07c16c8a2ed0884666e842720xdd4e4b720fb2517c4bc6f91ccb8725118e5770c628150x491f6ec665f54c4b3cffaa02ec594d31e6e26c0e2930x4f5a082c9d9c9714701de0bf426e9f893484618c30100x11f7017313f0c9549c5d415a8abc25243028514d31120x6839a994fccb9cb76241d809146906a3d13f89f13240x71cd1d9163d7cd563936837c61d97bb1a5337cc03350x77c9034ffc0f9219841aa8e1edbfb62017ef9fd134100xad9f6034017d35c338ac35778dd6c4c1abe4472a3580x4a1c396b22e4f5cc2428045b36d13737c400751536100x98cb57b779c5fd3f361cd5debc243303ae5baefd37130x29857298f274d6bf595eadc89e5464ccf9608a6c3840x95e35a26815a3ae9ad84a24464b174a29364da1839130x4afeb3b95b5b333759c0acdd96ce3f26314bb22b40130x325a37ee5e349b22b13b54b24be5145344e7b8f341110x4f772c93f56fd6958ce135f02847996c67e1f2ef42100xd4f6d91c577594060be328b013c9e9b0e8a2e5d84310x717e1a81c325cdccacb6e9fd9e92dd3e1bb84ae844110x1dd363724ec66c090a1228dfa1cd3d9cc806f3464520x64b4110476dd0beea78714c5ab71278818792cfa4640xe22290e740056a144af50f0b10962b5bcc18fc824720x34fd87046a183f4732a52bb7805ce207eebdafc548150xbd2fdc5e4e8d0ed7c48c1bad9c2f7793fc2c93034900xb3f47e2e8e2dcdd890ea00934b9d8234830dbc4a50110xcd29719c56cdb507030e6132132179e5807e1d3b5130xf9edb9b301916217de0d746a0542316bebe9e80652120x7a3801cbfe0cafed863d81210c1ec721eede49e553150x5caba3ec960efa210f5f3e1c22c567ca475ef3ec54120xf911b5d148e1b03fe6983c53411f76ea787723795510x06da2baa75c6ef752bf59f3812fa042ff81812095690x2b29f5aa2f34af51a78a5fac586004f749c6e6dc5790x55e033ababac0845cc9142e24f9ef0a641c51cbe5830xb62d207bb700071fba8a68312ca204ce4d994c335990x551d5c00fad905bdb99c4f70ec7590a10d3ff8ca6010x0d03b1845b5f8838d735142f185f9cf8f8d2db6c61130x3b5d9e49e7ede41cd9aa5a09f72a0384fd4ff51162130xa766b0278d14a9b7d32bf0307c0737a8ecf82ab16380xca85296f354e6e3d2a96ab497c01e5ccd4530cf16410x7bb29db7dd8aaaf1cd11487cea0d13730edb1df365120x547ef341b3cf3208753bb1b62d85a4e3fc2cffe066120xb890e1a99da4b2e0a9dde42f82f92d0946327cee
Finally, based on the fact that the message is the first to be signed by the
Merkle tree (i.e. using leaf node 0), the values of the leaf and interior nodes
that compose the authentication path from leaf to root are determined as described in
. These values are marked with
an asterisk ('*') in and .
The signature verification step was provided the following items:
OTS = (y[0] || y[1] || ... || y[p-1]) - from .Authentication Path = concatenation of (k-1)*h Merkle tree node values -
from and .Message Number = leaf number of Merkle tree.Merkle Public Key = root of Merkle tree - from .
Using Algorithm 4 of as a start, the potential OTS
public key was calculated from the value of the OTS. Since the actual OTS public key was
not provided to the verifier, the calculated key was checked for validity using the
pseudocode algorithm of and the provided values of the
Authentication Path and Message Number. Since the message was valid, the calculated value
of the root matched the Merkle public key. Otherwise, verification would have failed.
Key Element Index (i)SHA256-20 Result for w = 4 (F^15(x[i]))00x6eff4b0c224874ecc4e4f4500da53dbe2a030e4510x58ac2c6c451c7779d67efefdb12e5c3d85475a9420xb1f3e42e29c710d69268eed1bbdb7f5a500b793730x51d28e573aac2b84d659abb961c32c465e911b5540xa0ed62bccac5888f5000ca6a01e5ffefd442a1c650x44da9e145666322422c1e2b5e21627e05aeb436760x04e7ff9213c2655f28364f659c35d3086d7414e170x414cdb3215408b9722a02577eeb71f9e016e425180xa3ab06b90a2b20f631175daa9454365a4f408e9e90xe38acfd3c0a03faa82a0f4aeac1a7c04983fad25100xd95a289094ccce8ad9ff1d5f9e38297f9bb306ff110x593d148b22e33c32f18b66340bdaffceb3ad1a55120x16b53fbea11dc7ab70c8336ec3c23881ae5d51bf130xa639ca0cf871188cadd0020832c4f06e6ebd5f98140xe3ab3e0c5ad79d6c8c2a7e9a79856d4380941fe0150x8368c2933dabcde69c373867a9bf2dc78df97bea160xe3609fca11545da156a7779ae565b1e3c87902c0170xab029e62c7011772dc0589d79fad01aacf8d2177180xa8310f1c27c1aa481192de07d4397b8c4716e25f190xdbdbb14dbd9a5f03c1849af24b69b9e3f80faca2200x1a17399d555dec07d3d4f6d54b2b87d2bcaa398b210xf81c66cc522bfb203232e44d0003ed65d2462867220x202a625b8c5f22de6ea081af6da077cf5c63202f230x2e080f3591f5ff3d5de39c2698846cc107a09816240xa1d9c78c22f9810e3b7db2d59ad9f5fdd259f4d4250x658eeb85ebe0f4542c4d32dced2d7226929266b2260x67fae1a784f919577afc091504d82d31b4ba9fc7270xfc39fb43677fb2d433a6292f19c6e7320279655a280x491f6ec665f54c4b3cffaa02ec594d31e6e26c0e290x17cec813a5781409b11d2e4a85f62301c2fd8873300xc578eb105454d900c053eb55833db607aa5757e0310xaed094323290a41fd4b546919620e2f6b23916c8320x192b5a87b5124dc287e06cdd4ec7c0c11f67dda6330x4e9e2bdc1b0204d1ceeb68fb4159e752c40b9608340xf34c57ad9ce45d67fd32dc2737e6263bcc5cc61f350xf73bd27d376186310f83cc66e72060aeaccde371360xeea482511acd8be783e9be42b48799653b222db4370xa2e53196fec8676065b8f32b3e8498e66a4af3cf380x670c98185157e1b28d38f7dafb00796b434c8316390x441afbb265b93595389aaa66325de792f343f209400x7b6c50d20b5edc0bc90eb4b289770514cbc8d547410xfde6e862a7ba3534893a3e630e209a24be590b1e420xc59611200c20b2e73dfb24c84cedf4792d6daf10430x66e3527bee88373d18f91b230b53b569361f0a15440xd0fd79c7116198e689275fec9b4c46f4aac73293450x65f07406ad4241e7cf4174c5f284267292cdbc32460x7b1b5535d45f46542e2b876245b66ea83cde3d8f470x7a11620934eb0eb17e10e4a8bbd52aa4b020da0e480xbd2fdc5e4e8d0ed7c48c1bad9c2f7793fc2c9303490x00432602437252a0622a30676dbaaef3023328b9500x09a9c4b25034466a5acd7ff681af1c27e8f97577510x4b31481d52aa5e1a261064bbd87ea46479a6be23520xaca2ad4aa1264618ab633bf11cbca3cc8fa43091530x5caba3ec960efa210f5f3e1c22c567ca475ef3ec540x353e3ffcedfd9500141921cf2aebc2e111364dad550xe1c498c32169c869174ccf2f1e71e7202f45fba7560x5b8519a40d4305813936c7c00a96f5b4ceb603f1570x3b942ae6a6bd328d08804ade771a0775bb3ff8f8580x6f3be60ee1c34372599b8d634be72e168453bf10590xf700c70bac24db0aab1257940661f5b57da6e817600x85ccf60624b13663a290fa808c6bbecaf89523cd610xd049be55ab703c44f42167d5d9e939c830df960f620xd27a178ccc3b364c7e03d2266093a0d1dfdd9d51630xd73c53fdddbe196b9ab56fcc5c9a4a57ad868cd1640xb59a70a7372f0c121fa71727baaf6588eccec400650x9b5bf379f989f9a499799c12a3202db58b084eed660xccabf40f3c1dacf114b5e5f98a73103b4c1f9b55MTS Leaf (Level 3) Node NumberOTS Public Key (H(x[0] || x[1] || ... || x[p-1]))Member of Authentication Path of Message 000x2db55a72075fcfab5aedbef77bf6b371 dfb489d6e61ad2884a248345e691061810x8c6c6a1215bfe7fda10b7754e73cd984 a64823b1ab9d5f50feda6b151c0fee6d*20xc1fb91de68b3059c273e53596108ec7c f39923757597fe86439e91ce1c25fc84*30x1b511189baee50251335695b74d67c40 5a04eddaa79158a9090cc7c3eb204cbf*40xf3bcf088ccf9d00338b6c87e8f822da6 8ec471f88d1561193b3c017d20b3c97150x40584c059e6cc72fb61f7bd1b9c28e73 c689551e6e7de6b0b9b730fab923753160x1b1d09de1ca16ca890036e018d7e73de b39b07de80c19dcc5e55a699f021d88070x83a82632acaac5418716f4f357f5007f 719d604525dbe1831c09a2ead9400a5280xccb8b2a1d60f731b5f51910eb427e211 96090d5cd2a077f33968b425301e3fbd90x616767ebf3c1f3ec662d8c57c630c6ae b31853fd40a18c3d831f5490610c1f16100x5a4b3e157b66327c75d7f01304d188e2 cecd1b6168240c11a01775d581b01fb6110xf25744b8a1c2184ba38521801bf4727c 407b85eb5aef8884d8fbb1c12e2f6108120xaf8189f51874999162890f72e0ef25e6 f76b4ab94dc53569bdd66507f5ab0d8e130x96251e396756686645f35cd059da329f 7083838d56c9ccacebbaf8486af18844140x773d5206e40065d3553c3c2ed2500122 e3ee6fd2c91f35a57f084dc839aab1fc150xcda7fae67ce2c3ed29ce426fdcd3f2a8 eb699e47a67a52f1c94e89726ffe97faMTS Interior (Level 2) Node NumberNode Value (H(child_0 || child_1 || ... || child_k-1))Member of Authentication Path of Message 000xb6a310deb55ed48004133ece2aebb25e d74defb77ebd8d63c79a42b5b4191b0c10x71a0c8b767ade2c97ebac069383e4dfb a1c06d5fd3f69a775711ea6470747664*20x91109fa97662dc88ae63037391ac2650 f6c664ac2448b54800a1df748953af31*30xd277fb8c89689525f90de567068d6c93 565df3588b97223276ef8e9495468996*