]>
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 specifies
a general signature system using a Merkle tree. These
systems provide asymmetric authentication without
using large integer mathematics and 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 low
computational cost, but large signatures. 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. While the
specification of the algorithms follows these early references, the
security considerations makes use of more recent security analyses
(especially Buchmann, Dahmen, Ereth, Hulsing, and Ruckert 2011).
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 type. 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.
A byte can be considered as a sequence of eight bits, a sequence of four duets
(two bit unsigned integers), or a sequence of two quartets (four bit
unsigned integers). A bit has value 0 or 1. A duet has a value between
0 and 3, and a quartet has value between 0 and 15 decimal (F
hexadecimal).
If S is a byte string, then byte(S, i) denotes its i^th byte, where
byte(S, 0) is the leftmost byte. For example, if S = 0x0204ff, then byte(S, 0) is 0x02.
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.
When a and b are 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 a divided 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 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 m-byte strings (i.e. byte strings of length m) as input and returns m-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.
Note that in order to constrain what constitutes the "message" and establish
fixed sizes for the signature, a digest of the original message is
computed using a collision-resistant hash function, H (see
).
The signature system uses the parameters m, n, and w; they are all positive
integers. The algorithm description also uses the value p. These parameters
are summarized as follows:
m : the length in bytes of each element of an LDWM signaturen : the length in bytes of 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;
it is equivalent to the number of w-bit elements of ( H(message) || C(H(message)) )
as well as the number of n-byte strings that form the private key; it can be specified in terms of
u and v, as shown in .ls : the number of bits the checksum function C will left-shift the sum total of
hashing operations required by the verifier before returning a result
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 a direct result of the choices of n and w.
describes how p and ls depend on the other parameters.
A table illustrating various combinations of n, w, p, and ls is provided in .
The LDWM algorithm requires a robust one-way function to underpin the signature
generation and verification. Let this be defined as a hash function H that has
inputs of any integral byte length and has n-byte outputs.
In addition, let F be defined as a one-way function that 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_SHA256_M20_W1SHA256SHA256-20203212657LDWM_SHA256_M20_W2SHA256SHA256-20203221336LDWM_SHA256_M20_W4SHA256SHA256-2020324674LDWM_SHA256_M20_W8SHA256SHA256-2020328340
Here SHA256 denotes the NIST standard hash function.
SHA256-20 denotes that hash function with its final output truncated
to 20 bytes.
The LDWM private key must be an array of size p containing n-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.
The LDWM public key is generated from the private key through a series of
hashing operations using the functions F and H. Its value is the hash
(using H) of the concatenation of the elements of an array y. The content
of y is generated by iteratively hashing (using F) each element of
array x, (2^w - 1) times. The following algorithm shows pseudocode for
generating the public key.
A checksum is used to prevent the manipulation of an existing signature
in an attempt to produce a new signature for a different message outside of the
normal signing process. The security property 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 checksum function C is defined as follows where S is a
byte string provided to the function as an argument.
Implementation Note: Based on the previous fact, the implementation may therefore 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 repeatedly adding two w-bit numbers a total of
u = ceil(8*n/w) times requires at most (floor(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(floor(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 the values of the w-bit fields that compose
the hash of the message and its checksum to determine the number of times to apply
the function F to the elements of the private key. This signature is provided by the
signer to the verifier along with the message and the public key.
In order to verify a message with its signature (denoted as y',
an array of m-byte strings), the receiver must "complete" the series
of applications of F using the value of the message hash and its checksum. This should
result in a computation of the public key that matches the public key provided.
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 describe 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_m20_w1, which has 265 elements, each of which is a
20-octet string. An ldwm_signature always consists of a 32-bit
unsigned integer that indicates the ldwm_algorithm_type followed by an
array of equal-length octet strings. The number of octets in each
octet string, and the number of elements in the array, are determined
by the ldwm_algorithm_type field. A receiver MUST check the
ldwm_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 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
k-way 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) 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 LDWM 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 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 and a separate stack of integers
which keeps track of the level of the 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 public key verification algorithm.
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 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.
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 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", that starts with the
strings "MTS" and "LDWM" for the MTS and LDWM registries, respectively,
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
positive 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 32,768 (binary 1000000000000000) and
65,535 (binary 1111111111111111) 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 1 LDWM_SHA256_M20_W2 2 LDWM_SHA256_M20_W4 3 LDWM_SHA256_M20_W8 4
The MTS registry is as follows.
NameReferenceNumeric Identifier MTS_SHA256_K2_H201 MTS_SHA256_K4_H102 MTS_SHA256_K8_H73 MTS_SHA256_K16_H54
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").
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.
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 can 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 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 this action, the checksum will decrease, and 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 have 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 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.
&rfc2119;
&rfc2434;
&rfc4506;
A 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, w, p, and ls is provided in
.
Hash Length in Bytes (n)Winternitz Parameter (w)w-bit Elements in ChecksumLeft Shift (ls)Number of Elements (p)2018816820248842043443208202232197265322561333243467328203448197393482561974843499488205064110652264256261644341316482066
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:
mnwplkh2032467442
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 public/private key pairs of the one-time signatures are unique.
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 .
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 SHA-256-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"))0x0ba904eae8773b70c75333db4de2f3ac4 5a8ad4ddba1b242f0b3cfc199391dd81c
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 2) 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 1) Node NumberNode Value (H(child_0 || child_1 || ... || child_k-1))Member of Authentication Path of Message 000xb6a310deb55ed48004133ece2aebb25e d74defb77ebd8d63c79a42b5b4191b0c10x71a0c8b767ade2c97ebac069383e4dfb a1c06d5fd3f69a775711ea6470747664*20x91109fa97662dc88ae63037391ac2650 f6c664ac2448b54800a1df748953af31*30xd277fb8c89689525f90de567068d6c93 565df3588b97223276ef8e9495468996*