<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2246 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY rfc4346 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!--
<!ENTITY rfc4347 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4347.xml">
-->
<!ENTITY rfc4309 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY rfc4366 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY rfc5288 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5288.xml">
<!ENTITY ietf-tls-rfc4346-bis SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4346-bis.xml">
<!ENTITY ietf-tls-rfc4347-bis SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4347-bis.xml">
<!ENTITY ietf-tls-ctr SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-ctr.xml">
<!ENTITY rescorla-tls-suiteb SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.rescorla-tls-suiteb.xml">
<!--
<!ENTITY I-D.draft-ietf-tls-rfc4347-bis   PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tls-rfc4347-bis-03.xml">
-->

<!ENTITY rfc2434 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY rfc3979 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3979.xml">
<!ENTITY rfc4309 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY rfc4506 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4506.xml">
<!ENTITY rfc4879 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4879.xml">
<!ENTITY rfc5246 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5116 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml">
<!ENTITY rfc5430 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5430.xml">
<!ENTITY rfc5246 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc4492 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY rfc6090 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6090.xml">

]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="no"?>
<rfc ipr="trust200902" category="info" docName="draft-mcgrew-hash-sigs-11">

  <front>

    <title abbrev="Hash-Based Signatures">Hash-Based Signatures</title>

    <author fullname="David McGrew" initials="D" surname="McGrew">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>13600 Dulles Technology Drive</street>
          <city>Herndon</city>
          <code>20171</code>
          <region>VA</region>
          <country>USA</country>
        </postal>
        <email>mcgrew@cisco.com</email>
      </address>
    </author>

    <author fullname="Michael Curcio" initials="M" surname="Curcio">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>7025-2 Kit Creek Road</street>
          <city>Research Triangle Park</city>
          <code>27709-4987</code>
          <region>NC</region>
          <country>USA</country>
        </postal>
        <email>micurcio@cisco.com</email>
      </address>
    </author>

    <author fullname="Scott Fluhrer" initials="S" surname="Fluhrer">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <country>USA</country>
        </postal>
        <email>sfluhrer@cisco.com</email>
      </address>
    </author>

    <date month="April" year="2018"/>
    <!-- Is the "Security" area applicable here? -->
    <area> IRTF </area>
    <workgroup> Crypto Forum Research Group</workgroup>
    <abstract>
      <t>
      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.
      </t>
    </abstract>

  </front>

  <middle>

<section title="Introduction">
<t>
One-time signature systems, and general purpose signature systems
built out of one-time signature systems, have been known since 1979
<xref target="Merkle79"/>, were well studied in the 1990s <xref
target="USPTO5432852"/>, 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
<!-- (see <xref target="pq"/>) --> and their
suitability for compact verifier implementations.
</t>

<t>
This note describes the Leighton and Micali adaptation <xref
target="USPTO5432852"/> of the original
Lamport-Diffie-Winternitz-Merkle one-time signature system
<xref target="Merkle79"/> <xref target="C:Merkle87"/><xref
target="C:Merkle89a"/><xref target="C:Merkle89b"/> and general
signature system <xref target="Merkle79"/> with enough specificity to
ensure interoperability between implementations.
</t>

<!-- 

An example implementation is given in an appendix.  


DAM - add Lamport, Diffie, and Winternitz citations -->
<t>
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.  
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
This note is structured as follows.
Notation is introduced in <xref target="notation"/>.  The LM-OTS
signature system is described in <xref target="ldwm"/>, and the LMS
and HSS N-time signature systems are described in
<xref target="merkle"/> and <xref target="hss"/>, respectively.
Sufficient detail is provided to ensure interoperability.
The public formats are described in <xref target="ldwm_xdr"/>.
The rationale for design decisions are given in <xref target="rationale"/>.
<!-- 
<xref target="testing"/>
describes test considerations and contains test cases that can be used
to validate an implementation.  
-->
The changes made to this document over previous versions is listed in <xref target="History"/>.
The IANA registry for these signature
systems is described in <xref target="IANA"/>.
Intellectual Property issues are discussed in <xref target="IP"/>.
Security considerations are presented in <xref target="Security"/>.
</t>
<section title="Conventions Used In This Document">
  <t>
    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 <xref target="RFC2119" />.
  </t>
</section>
</section>


<section title="Interface" anchor="interface">
<t>
  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.
<!--
To make this fact explicit in the interface, we use a
  functional programming approach, in which the key generation,
  signing, and verification algorithms do not have any side effects.
  The signing algorithm returns both a signature and a different
  private key value, which can be used to sign additional messages.
-->
</t>
  <t>
    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.
  </t>
  <t>
    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.
  </t>
  <t>
    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.
  </t>
<t>
   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.
</t>
</section>

<section title="Notation" anchor="notation">
<section title="Data Types" anchor="datatypes">
<t>
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.
</t>
<t>
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.
</t>
<section title="Operators" anchor="operators">
<t>
When a and b are real numbers, mathematical operators are defined as follows:
<list>
<t>^ : a ^ b denotes the result of a raised to the power of b</t>
<t>* : a * b denotes the product of a multiplied by b</t>
<t>/ : a / b denotes the quotient of a divided by b</t>
<t>% : a % b denotes the remainder of the integer division of a by b</t>
<t>+ : a + b denotes the sum of a and b</t>
<t>- : a - b denotes the difference of a and b</t>
</list>
The standard order of operations is used when evaluating arithmetic expressions.
</t>
<t>
When B is a byte and i is an integer, then B >> i denotes the logical
right-shift operation by i positions.
Similarly, B &lt;&lt; i denotes the logical left-shift operation.
</t>
<t>
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.
</t>
<t>
The i-th element in an array A is denoted as A[i].
</t>
</section>

<section title="Functions" anchor="functions">
<t>
If r is a non-negative real number, then we define the following functions:
<list>
<t>ceil(r) : returns the smallest integer larger than r</t>
<t>floor(r) : returns the largest integer smaller than r</t>
<t>lg(r) : returns the base-2 logarithm of r</t>
</list>
</t>
</section>

<section title="Strings of w-bit elements">
<t>
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.
</t>
<t>
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:
</t>
<figure>
<preamble>If S is a string, i is a positive integer, and w is a member of the set { 1, 2, 4, 8 }, then
coef(S, i, w) is the i-th, w-bit value, if S is interpreted as a
sequence of w-bit values.  That is,
</preamble>
<artwork>
    coef(S, i, w) = (2^w - 1) AND
                    ( byte(S, floor(i * w / 8)) >>
                      (8 - (w * (i % (8 / w)) + w)) )
</artwork>
</figure>
<figure>
<preamble>For example, if S is the string 0x1234,
then coef(S, 7, 1) is 0 and coef(S, 0, 4) is 1.</preamble>
<artwork>
<![CDATA[
                   S (represented as bits)
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      | 0| 0| 0| 1| 0| 0| 1| 0| 0| 0| 1| 1| 0| 1| 0| 0|
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                             ^
                             |
                       coef(S, 7, 1)


              S (represented as four-bit values)
      +-----------+-----------+-----------+-----------+
      |     1     |     2     |     3     |     4     |
      +-----------+-----------+-----------+-----------+
            ^
            |
      coef(S, 0, 4)]]>
</artwork>
</figure>
<t>
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.
</t>
</section>

</section>


<section title="Typecodes">
<t>
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 <xref target="ldwm_xdr"/>).
</t>
</section>

</section>



<section anchor="ldwm" title="LM-OTS One-Time Signatures">
<t>
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.
</t>
<t>
As part of the signing process, a digest of the original message is
computed using the cryptographic hash function H (see <xref
target='ldwm_params' />), and the resulting digest is signed.  
</t>
<t>
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 a parameter q, which indicates the leaf of the Merkle tree where the OTS public key appears.
This parameter is used as part of the security string, as listed in <xref target="secstring"/>.
When the LM-OTS signature
system is used outside of an N-time signature system, this value
SHOULD be set to the all-zero value.
</t>
<section title='Parameters' anchor='ldwm_params'>
<t>
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:
<list>
<!-- <t>m : the length in bytes of each element of an LM-OTS signature</t> -->
<t>n : the number of bytes of the output of the hash function</t>
<t>w : the width (in bits) of the Winternitz coefficients; it is a member of the set {&nbsp;1,&nbsp;2,&nbsp;4,&nbsp;8&nbsp;}</t>
<t>p : the number of n-byte string elements that make up the LM-OTS signature</t>
<t>ls : the number of left-shift bits used in the checksum function Cksm (defined in <xref target='ldwm_msg_chksum'/>)</t>
<t>
 H : a second-preimage-resistant cryptographic hash function that accepts byte strings of any length, and returns an n-byte string
<!-- F has m-byte inputs and m-byte outputs. -->
</t>
</list>
</t>
<t>
For more background on the cryptographic security requirements on H, see
the <xref target="Security"/>.
</t>
<t>
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 <xref
target='ldwm_param_opts' />.  A table illustrating various
combinations of n, w, p, and ls is provided in <xref
target='ldwm_sig_table' />.
</t>
<t>
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 about half that on average).
</t>
<texttable anchor='ldwm_sig_table'>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>H</ttcol>
<ttcol align='left'>n</ttcol>
<ttcol align='left'>w</ttcol>
<ttcol align='left'>p</ttcol>
<ttcol align='left'>ls</ttcol>
<c>LMOTS_SHA256_N32_W1</c> <c>SHA256</c>     <c>32</c> <c>1</c> <c>265</c> <c>7</c> 
<c>LMOTS_SHA256_N32_W2</c> <c>SHA256</c>     <c>32</c> <c>2</c> <c>133</c> <c>6</c> 
<c>LMOTS_SHA256_N32_W4</c> <c>SHA256</c>     <c>32</c> <c>4</c> <c>67</c>  <c>4</c> 
<c>LMOTS_SHA256_N32_W8</c> <c>SHA256</c>     <c>32</c> <c>8</c> <c>34</c>  <c>0</c> 
</texttable>
<t>
Here SHA256 denotes the SHA-256 hash fucntion defined in NIST standard <xref target="FIPS180"/>.  
</t>

</section>
<section title='Private Key' anchor='ldwm_prv_key'>
<t>
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.
</t>
<figure>
<preamble>Algorithm 0: Generating a Private Key</preamble>
<artwork>
  1. retrieve the values of q and I (the 16-byte
     identifier of the LMS public/private keypair) from the LMS tree that this LM-OTS private
     key will be used with

  2. set type to the typecode of the algorithm

  3. set n and p according to the typecode and Table 1

  4. compute the array x as follows:
     for ( i = 0; i &lt; p; i = i + 1 ) {
       set x[i] to a uniformly random n-byte string 
     }

  5. return u32str(type) || I || u32str(q) || x[0] || x[1] || ... || x[p-1]
</artwork>
<postamble>


</postamble>
</figure>
<t>
An implementation MAY use a pseudorandom method to compute x[i], as
suggested in <xref target="Merkle79"/>, page 46.  The details of the
pseudorandom method do not affect interoperability, but the
cryptographic strength MUST match that of the LM-OTS algorithm.
<xref target="PRG"/> provides an example of a pseudorandom method
for computing the LM-OTS private key.  
</t>

<!--
<section title="Pseudorandom Private Key Generation">
<t>
  ctr_kdf_sp800_108() implements the hash/hmac based counter mode key
  derivation function, or CTR KDF, as it is specified in NIST Special
  Publication 800-108, Section 5.1.  The details of this
  implementation are:
 
    - the counter field "i" is a four-byte unsigned integer
  
    - the Label field consists of a one-byte value indicating the
      purpose of the derived keying material (0xf0 is for LDWM, and
      0x40 is for MTS) followed by a seven-byte unsigned integer that
      indicates the element number for LDWM, and indicates the leaf
      number for MTS.
 
    - the Context field is empty, i.e. a zero-length string
 
    - the field "L" that specifies the length, in bits, of the
      derived keying material is a four-byte unsigned integer.  In
      our case, it is always equal to 256 for SHA-256.
  
</t>
</section>
-->
</section>
<section title='Public Key' anchor='ldwm_pub_key'>
<t>
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.  
</t>
<t>
<!--
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 public key is generated from the private key using the following
algorithm, or any equivalent process.
</t>
<figure>
<preamble>Algorithm 1: Generating a One Time Signature Public Key From a Private Key</preamble>
<artwork>
  1. set type to the typecode of the algorithm

  2. set the integers n, p, and w according to the typecode and Table 1

  3. determine x, I and q from the private key

  4. compute the string K as follows:
     for ( i = 0; i &lt; p; i = i + 1 ) {
       tmp = x[i] 
       for ( j = 0; j &lt; 2^w - 1; j = j + 1 ) {
          tmp = H(I || u32str(q) || u16str(i) || u8str(j) || tmp)
       }
       y[i] = tmp
     }
     K = H(I || u32str(q) || u16str(D_PBLC) || y[0] || ... || y[p-1])

  5. return u32str(type) || I || u32str(q) || K
</artwork>
</figure>
<t>
  The public key is the value returned by Algorithm 1.
<!--  <xref
  target="ldwm_xdr"/> specifies the enumeration and more formally
  defines the format.
-->
</t>
<!--

  I   - 16 bytes
  q   - 4 bytes
  i   - 2 bytes
  j   - 1 bytes
  tmp - 32 bytes
 
  total - 55 bytes (needs to be <= 55 for sha256)
-->

</section>


<section title='Checksum' anchor='ldwm_msg_chksum'>
<t>
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 <xref target='Security' />.
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:
</t>
<figure>
<preamble>Algorithm 2: Checksum Calculation</preamble>
<artwork>
  sum = 0
  for ( i = 0; i &lt; (n*8/w); i = i + 1 ) {
    sum = sum + (2^w - 1) - coef(S, i, w)
  }
  return (sum &lt;&lt; ls)
</artwork>
<postamble>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.</postamble>
</figure>
<!--
<t>
<list style="empty">
<t>
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.
</t>
</list>
</t>
-->
</section>
<section title='Signature Generation' anchor='ldwm_sig_gen'>
<t>
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 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.
</t>

<figure>
<preamble>Algorithm 3: Generating a One Time Signature From a Private Key and a Message</preamble>
<artwork>
  1. set type to the typecode of the algorithm

  2. set n, p, and w according to the typecode and Table 1

  3. determine x, I and q from the private key

  4. set C to a uniformly random n-byte string 

  5. compute the array y as follows:
     Q = H(I || u32str(q) || u16str(D_MESG) || C || message)
     for ( i = 0; i &lt; p; i = i + 1 ) {
       a = coef(Q || Cksm(Q), i, w)
       tmp = x[i] 
       for ( j = 0; j &lt; a; j = j + 1 ) {
          tmp = H(I || u32str(q) || u16str(i) || u8str(j) || tmp)
       }
       y[i] = tmp
     }

   6. return u32str(type) || C || y[0] || ... || y[p-1]
</artwork>
<postamble>Note that this algorithm results in a signature whose
elements are intermediate values of the elements computed by the
public key algorithm in <xref target='ldwm_pub_key' />.</postamble>
</figure>
<t>
  The signature is the string returned by Algorithm 3.  <xref
  target="ldwm_xdr"/> specifies the typecode and more formally
  defines the encoding and decoding of the string.
</t>
<!--

Implementation note: for SHA-256, the number of bytes in 

   I || q || i || j || tmp

is 16+4+2+1+32 = 55

Thus, the invocation of H() that is repeated many times in Algorithms
2 and 3 will each use only one invocation of the compression function.

<t>
The signature should be provided by the signer to the verifier,
with the message and the public key.
</t>
-->
</section>
<section title='Signature Verification' anchor='ldwm_sig_vrf'>
<t>
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. 
</t>
<figure>
<preamble>Algorithm 4a: Verifying a Signature and Message Using a
Public Key</preamble>
<artwork>
  1. if the public key is not at least four bytes long, return INVALID

  2. parse pubtype, I, q, and K from the public key as follows:
     a. pubtype = strTou32(first 4 bytes of public key)

     b. set n according to the pubkey and Table 1; if the public key
        is not exactly 24 + n bytes long, return INVALID

     c. I = next 16 bytes of public key

     d. q = strTou32(next 4 bytes of public key)

     e. K = next n bytes of public key

  3. compute the public key candidate Kc from the signature,
     message, and the identifiers I and q obtained from the 
     public key, using Algorithm 4b.  If Algorithm 4b returns
     INVALID, then return INVALID.

  4. if Kc is equal to K, return VALID; otherwise, return INVALID
</artwork>
</figure>
<figure>
<preamble>Algorithm 4b: Computing a Public Key Candidate Kc from a
Signature, Message, Signature Typecode Type, and identifiers I, q
</preamble>
<artwork>
  1. if the signature is not at least four bytes long, return INVALID

  2. parse sigtype, C, and y from the signature as follows:
     a. sigtype = strTou32(first 4 bytes of signature)

     b. if sigtype is not equal to pubtype, return INVALID

     c. set n and p according to the pubtype and Table 1;  if the
     signature is not exactly 4 + n * (p+1) bytes long, return INVALID

     d. C = next n bytes of signature

     e.  y[0] = next n bytes of signature
         y[1] = next n bytes of signature
         ...
       y[p-1] = next n bytes of signature

  3. compute the string Kc as follows
     Q = H(I || u32str(q) || u16str(D_MESG) || C || message)
     for ( i = 0; i &lt; p; i = i + 1 ) {
       a = coef(Q || Cksm(Q), i, w)
       tmp = y[i] 
       for ( j = a; j &lt; 2^w - 1; j = j + 1 ) {
          tmp = H(I || u32str(q) || u16str(i) || u8str(j) || tmp)
       }
       z[i] = tmp
     }
     Kc = H(I || u32str(q) || u16str(D_PBLC) || z[0] || z[1] || ... || z[p-1]) 

  4. return Kc
</artwork>
</figure>
</section>

</section>

<section anchor="merkle" title="Leighton-Micali Signatures">
<t>
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.
</t>
<t>
  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 &lt; 2^h, 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.
</t>

<section title="Parameters">
<t>
  An LMS system has the following parameters:
  <list>
    <t>
      h : the height of the tree, and
    </t>
    <t>
      m : the number of bytes associated with each node.
    </t>
    <t>
      H : a second-preimage-resistant cryptographic hash function that accepts byte strings of any length, and
      returns an m-byte string.
    </t>
  </list>
There are 2^h leaves in the tree.  The hash function used within the
LMS system SHOULD be the same as the hash function used within the
LM-OTS system used to generate the leaves.
</t>
<texttable anchor='lms_table'>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>H</ttcol>
<ttcol align='left'>m</ttcol>
<ttcol align='left'>h</ttcol>
<c>LMS_SHA256_M32_H5</c>  <c>SHA256</c> <c>32</c> <c>5</c>
<c>LMS_SHA256_M32_H10</c> <c>SHA256</c> <c>32</c> <c>10</c>
<c>LMS_SHA256_M32_H15</c> <c>SHA256</c> <c>32</c> <c>15</c>
<c>LMS_SHA256_M32_H20</c> <c>SHA256</c> <c>32</c> <c>20</c>
<c>LMS_SHA256_M32_H25</c> <c>SHA256</c> <c>32</c> <c>25</c>
</texttable>
</section>

<section anchor="mts_priv" title="LMS Private Key">
<t>
  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:
</t>
<figure>
<preamble>
Algorithm 5: Computing an LMS Private Key.
</preamble>
<artwork>
   1. determine h and m from the typecode and Table 2.

   2. set I to a uniformly random 16-byte string

   3. compute the array OTS_PRIV[] as follows:
      for ( q = 0; q &lt; 2^h; q = q + 1) {
         OTS_PRIV[q] = LM-OTS private key with identifiers I, q
      }

   4. q = 0
</artwork>
</figure>

<t>
  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.
  <xref target="PRG"/> provides an example of a pseudorandom method
    for computing an LMS private key.  
</t>
<t>
  The signature generation logic uses q as the next leaf to use, hence
  step 3 starts it off at the left-most one.
</t>
</section>
<section anchor="mts_alg" title="LMS Public Key">
<t>
  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
</t>
<figure>
<artwork>
  T[r]=/ H(I||u32str(r)||u16str(D_LEAF)||OTS_PUB_HASH[r-2^h])   if r >= 2^h,
       \ H(I||u32str(r)||u16str(D_INTR)||T[2*r]||T[2*r+1]) otherwise.        
</artwork>
</figure>
<t>
  The LMS public key is the string
</t>

<figure>
<artwork>
u32str(type) || u32str(otstype) || I || T[1]
</artwork>
</figure>

<t>
  <xref target="ldwm_xdr"/> 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 <xref target="iterativeLMS"/>.
</t>
</section>
<section anchor="mts_sig" title="LMS Signature">
<t>
An LMS signature consists of
<list>
  <t>
    the number q of the leaf associated with the LM-OTS signature,
    as a four-byte unsigned integer in network byte order,
  </t>
  <t>
    an LM-OTS signature,
  </t>
  <t>
    a typecode indicating the particular LMS algorithm,
  </t>
  <t>
    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.
  </t>
</list>
Symbolically, the signature can be represented as
</t>
<figure>
<artwork>
    u32str(q) || lmots_signature || u32str(type) ||
              path[0] || path[1] || path[2] || ... || path[h-1]
</artwork>
</figure>
<t> <xref target="ldwm_xdr"/> 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 (or 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 bthe 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.
</t>
<t>
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 pubic 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 the T[3]** node which is the sibling of the third Node* (T[2]*) on the path.
</t>
<figure>
<artwork>
                             Root
                              |
              ---------------------------------
              |                               |
            T[2](*)                        T[3](**)
              |                               |
       ------------------            -----------------
       |                |            |               |
    T(4)**           T[5](*)        T[6]            T[7]
       |                |            |               |
   ---------       ----------     --------       ---------
   |       |       |        |     |      |       |       |
  leaf    leaf    OTS  leaf(**) leaf   leaf    leaf    leaf
       
</artwork>
</figure>
<t>
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 wsa 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.

</t>
<section anchor="mts_sig_gen" title="LMS Signature Generation">
  <t>
    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.  
  </t>
  <t>
    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.
  </t>
  <t>
    Several useful time/storage tradeoffs are described in the
    'Small-Memory LM Schemes' section of <xref target="USPTO5432852"/>.
  </t>
</section>
<section anchor="mts_sig_vrf" title="LMS Signature Verification">
<t>
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.
</t>
<t>
<figure>
<preamble>Algorithm 6: LMS Signature Verification </preamble>
<artwork> 
  1. if the public key is not at least eight bytes long, return 
     INVALID

  2. parse pubtype, I, and T[1] from the public key as follows:

     a. pubtype = strTou32(first 4 bytes of public key)

     b. ots_typecode = strTou32(next 4 bytes of public key)

     c. set m according to pubtype, based on Table 2

     d. if the public key is not exactly 24 + m bytes 
        long, return INVALID

     e. I = next 16 bytes of the public key

     f. T[1] = next m bytes of the public key

  3. compute the LMS Public Key Candidate Tc from the signature,
     message, identifier, pubtype and ots_typecode using Algorithm 6a.

  4. if Tc is equal to T[1], return VALID; otherwise, return INVALID
</artwork>
</figure>
<figure>
<preamble>Algorithm 6a: Computing an LMS Public Key Candidate from a
Signature, Message, Identifier, and algorithm typecode </preamble>
<artwork>
  1. if the signature is not at least eight bytes long, return INVALID

  2. parse sigtype, q, lmots_signature, and path from the signature as
     follows: 

    a. q = strTou32(first 4 bytes of signature)

    b. otssigtype = strTou32(next 4 bytes of signature)

    c. if otssigtype is not the OTS typecode from the public key, return INVALID

    d. set n, p according to otssigtype and Table 1; if the
    signature is not at least 12 + n * (p + 1) bytes long, return INVALID

    e. lmots_signature = bytes 4 through 8 + n * (p + 1) - 1 of signature

    f. sigtype = strTou32(4 bytes of signature at location 8 + n * (p + 1))

    f. if sigtype is not the LM typecode from the public key, return INVALID

    g. set m, h according to sigtype and Table 2

    h. if q >= 2^h or the signature is not exactly 12 + n * (p + 1) + m * h bytes long, return INVALID

    i. set path as follows:
          path[0] = next m bytes of signature
          path[1] = next m bytes of signature
          ...
          path[h-1] = next m bytes of signature
 
  3. Kc = candidate public key computed by applying Algorithm 4b 
     to the signature lmots_signature, the message, and the 
     identifiers I, q

  4. compute the candidate LMS root value Tc as follows:
     node_num = 2^h + q
     tmp = H(I || u32str(node_num) || u16str(D_LEAF) || Kc)
     i = 0
     while (node_num > 1) {
       if (node_num is odd):
         tmp = H(I||u32str(node_num/2)||u16str(D_INTR)||path[i]||tmp)
       else:
         tmp = H(I||u32str(node_num/2)||u16str(D_INTR)||tmp||path[i])
       node_num = node_num/2
       i = i + 1
     }
     Tc = tmp

  5. return Tc
</artwork>
</figure>
</t>
<!-- I don't think we need to say this, actually. 
<t>
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 LMS public key.
</t>
-->
</section>
</section>
</section>

<section anchor="hss" title="Hierarchical signatures">
<t>
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 an LMS scheme as a component.  
HSS, in essence, utilizes a tree of LMS trees.
There is a single LMS tree at level 0 (the root).
Each LMS tree at level i is used to sign 2^h objects (where h is the
height of trees at level i).  If i &lt; L-1, then each object will be
another LMS tree at level i+1; if i = L-1, we've reached the bottom of
the HSS tree, and so each object is an individual message.
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.
</t>
<t>
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 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).
</t>
<t>
Each level of 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:
<list>
  <t>
 prv[i] is the LMS private key of the i-th level,
  </t>
  <t>
 pub[i] is the LMS public key of the i-th level (which includes
 the identifier I as well as the key value K),
  </t>
  <t>
 sig[i] is the LMS signature generated using the private key of the i-th level, 
  </t>
</list>
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.
</t>
<t>
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.  
</t>

<section title="Key Generation">
<t> 
  When an HSS key pair is generated, the key pair for each level
  MUST have its own identifier I.
</t>
<t>
  To generate an HSS private and public key pair, new LMS private and
  public keys are generated for prv[i] and pub[i] for i=0, ... , L-1.
  These key pairs, and their identifiers, MUST be generated
  independently.
<!--
  All of the information of the leaf level L-1,
  including the private key, MUST NOT be stored in nonvolatile memory.  
  Letting Nnv denote the lowest level for which prv[Nnv] is stored
  in nonvolatile memory, there are Nnv nonvolatile levels, and 
  L-Nnv volatile levels.  For security, Nnv should be as close
  to one as possible (see <xref target="stateful"/>).
-->
</t>
<t>
  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.
</t>
<t>
  The HSS private key consists of prv[0], ... , prv[L-1].  The values
  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.
</t>
<t>
  Here is some pseudocode that explains this key generation logic
</t>
<figure>
<preamble>Algorithm 7: Generating an HSS keypair </preamble>
<artwork>
  1. generate L LMS key pairs, as specified in sections 5.2 and 5.3

  2. sign each child key pair with the private key of its parent:
     i  = 0
     while (i &lt; L-1) {
         sig[i] = lms_signature( pub[i+1], priv[i] )
         i = i + 1
     }

  3. return u32str(L) || pub[0]

</artwork>
</figure>
<t>
  Note that the generation of the non-root LMS key pair, and the operations
  of step 2 can be delayed until the generation of the first signature,
  should it be advantageous for the implementation to do so.
</t>

</section>
<section anchor="siggen" title="Signature Generation">
<t>
To sign a message using the private key prv, the following
steps are performed:
<list>
  <t>
    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.
  </t>
  <t> 
    The message is signed with prv[L-1], and the value sig[L-1] is set to
    that result.
  </t>
  <t>
    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].
  </t>
    <t>
    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.
  </t>
</list>
</t>
<t>
  Here is some pseudocode of the above logic
</t>
<figure>
<preamble>Algorithm 7a: Generating an HSS signature </preamble>
<artwork>
  1. If the message-signing key prv[L-1] is exhausted, regenerate that
     key pair, togheter with any parent key paris that might be necessary.
     If the root key pair is exhausted, then the HSS key pair is exhausted
     and it MUST NOT generate any more signatures.

     d = L
     while (prv[d-1].q == 2^(prv[d-1].h)) {
         if (d == 0)
             return FAILURE
         d = d - 1
     }
     while (d &lt; L) {
         create lms keypair pub[d], prv[d]
         sig[d-1] = lms_signature( pub[d], prv[d-1] )
         d = d + 1
     }

  2. sign the message
     sig[L-1] = lms_signature( msg, prv[L-1] )

  3. Create the list of signed public keys
     i = 0;
     while (i &lt; L-1) {
         signed_pub_key[i] = sig[i] || pub[i+1]
         i = i + 1
     }

  4. return u32str(L-1) || signed_pub_key[0] || ... || signed_pub_key[L-2] || sig[L-1]

</artwork>
</figure>

<t>
  In the specific case of L=1, the format of an HSS signature is
</t>
<figure>
<artwork>
   u32str(0) || sig[0]
</artwork>
</figure>
<t>
  In the general case, the format of an HSS signature is
</t>
<figure>
<artwork>
   u32str(Nspk) || signed_pub_key[0] || ... || signed_pub_key[Nspk-1] || sig[Nspk]
</artwork>
</figure>
<t>
  which is equivalent to
</t>
<figure>
<artwork>
   u32str(Nspk) || sig[0] || pub[1] || ... || sig[Nspk-1] || pub[Nspk] || sig[Nspk]
</artwork>
</figure>

</section>
<section title="Signature Verification">
<t>
To verify a signature sig and message using the public key pub, the
following steps are performed:
</t>
<figure>
<artwork>
<![CDATA[
   The signature S is parsed into its components as follows:

   Nspk = strTou32(first four bytes of S)
   if Nspk+1 is not equal to the number of levels L in pub:
      return INVALID
   for (i = 0; i < Nspk; i = i + 1) {
      siglist[i] = next LMS signature parsed from S
      publist[i] = next LMS public key parsed from S
   }
   siglist[Nspk] = next LMS signature parsed from S

   key = pub
   for (i = 0; i < Nspk; i = i + 1) {
      sig = siglist[i]
      msg = publist[i]
      if (lms_verify(msg, key, sig) != VALID):
          return INVALID
      key = msg
   return lms_verify(message, key, siglist[Nspk])        
]]>
</artwork>
</figure>
<t>
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.
</t>
</section>

</section>


<section title="Formats" anchor="ldwm_xdr">
<figure>
<preamble>
The signature and public key formats are formally defined
using the External Data Representation (XDR) <xref target="RFC4506" />
in order to provide an unambiguous, machine readable definition.  For
clarity, we also include a private key format as well, though
consistency is not needed for interoperability and an implementation
MAY use any private key format.  Though XDR is used, these formats are
simple and easy to parse without any special tools.  An illustration
of the layout of data in these objects is provided below.  

The definitions are as follows:</preamble>
<artwork>
<![CDATA[
/* one-time signatures */

enum lmots_algorithm_type {
  lmots_reserved       = 0,
  lmots_sha256_n32_w1  = 1,
  lmots_sha256_n32_w2  = 2,
  lmots_sha256_n32_w4  = 3,
  lmots_sha256_n32_w8  = 4
};

typedef opaque bytestring32[32];

struct lmots_signature_n32_p265 {
  bytestring32 C;
  bytestring32 y[265];
};

struct lmots_signature_n32_p133 {
  bytestring32 C;
  bytestring32 y[133];
};

struct lmots_signature_n32_p67 {
  bytestring32 C;
  bytestring32 y[67];
};

struct lmots_signature_n32_p34 {
  bytestring32 C;
  bytestring32 y[34];
};

union lmots_signature switch (lmots_algorithm_type type) {
 case lmots_sha256_n32_w1:
   lmots_signature_n32_p265 sig_n32_p265;
 case lmots_sha256_n32_w2:
   lmots_signature_n32_p133 sig_n32_p133;
 case lmots_sha256_n32_w4:
   lmots_signature_n32_p67  sig_n32_p67;
 case lmots_sha256_n32_w8:
   lmots_signature_n32_p34  sig_n32_p34;
 default:
   void;   /* error condition */
}; 


/* hash based signatures (hbs) */ 

enum lms_algorithm_type {
  lms_reserved       = 0,
  lms_sha256_n32_h5  = 5,
  lms_sha256_n32_h10 = 6,
  lms_sha256_n32_h15 = 7,
  lms_sha256_n32_h20 = 8,
  lms_sha256_n32_h25 = 9,
};

/* leighton-micali signatures (lms) */

union lms_path switch (lms_algorithm_type type) {
 case lms_sha256_n32_h5:
   bytestring32 path_n32_h5[5];
 case lms_sha256_n32_h10:
   bytestring32 path_n32_h10[10];
 case lms_sha256_n32_h15:
   bytestring32 path_n32_h15[15]; 
 case lms_sha256_n32_h20:
   bytestring32 path_n32_h20[20]; 
 case lms_sha256_n32_h25:
   bytestring32 path_n32_h25[25]; 
 default:
   void;     /* error condition */
};

struct lms_signature {
  unsigned int q;
  lmots_signature lmots_sig;               
  lms_path nodes;
};

struct lms_key_n32 {
  lmots_algorithm_type ots_alg_type;
  opaque I[16];                    
  opaque K[32];                
};    

union lms_public_key switch (lms_algorithm_type type) {
 case lms_sha256_n32_h5:
 case lms_sha256_n32_h10:
 case lms_sha256_n32_h15:
 case lms_sha256_n32_h20:
 case lms_sha256_n32_h25:
      lms_key_n32 z_n32;
 default:
   void;     /* error condition */
};

/* hierarchical signature system (hss)  */

struct hss_public_key {
  unsigned int L;
  lms_public_key pub;
};

struct signed_public_key {
  lms_signature sig;
  lms_public_key pub;
}

struct hss_signature {
  signed_public_key signed_keys<7>;
  lms_signature sig_of_message;
};]]>
</artwork>
</figure>
<!--
<t>
The layout of the data inside of public keys, signatures, and private
keys of a two level HSS scheme is illustrated below, using the
following notation.  Each line describes a single object, and
indentation is used to show that an object is contained in another
object.  Some of these objects do not appear explicitly in the data
format, as they are merely logical groupings.  Objects that do appear
explicitly are indicated by an asterisk (*).  The lengths of some
objects is variable, and some object names are incomplete (because
more than one name might appear), so this diagram is meant as a
conceptual aid only, and not a precise definition.
</t>
<figure>
<artwork>
<![CDATA[
hss_public_key  
   * hss_algorithm_type
     lms_public_key       
        * lms_algorithm_type
          lms_public_key_n   
             * lmots_algorithm_type 
             * I
             * value
]]>
</artwork>
</figure>
<figure>
<artwork>
<![CDATA[
hss_private_key 
   * hss_algorithm_type
     lms_private_key      
        * lms_algorithm_type
          lms_public_key_n    
             * lmots_algorithm_type
             * I
             * value
     lms_private_key      
        * lms_algorithm_type
          lms_public_key_n    
             * lmots_algorithm_type
             * I
             * value
]]>
</artwork>
</figure>
<figure>
<artwork>
<![CDATA[
hss_signature   
   * hss_algorithm_type
     lms_public_key
        * lms_algorithm_type
          lms_key_n   
             * lmots_algorithm_type 
             * I
             * value
     lms_signature        
        lmots_signature
           * lmots_algorithm_type 
           * C
           * q
           * y[p]
        lms_path               
           * lms_algorithm_type
           * path[h]
     lms_signature        
        lmots_signature
           * lmots_algorithm_type 
           * C
           * q
           * y[p]
        lms_path               
           * lms_algorithm_type
           * path[h]
]]>
</artwork>
</figure>
-->
</section>


<section anchor="rationale" title="Rationale">
<t>
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.
</t>
<t>
We adopt the techniques described by Leighton and Micali to mitigate
attacks that amortize their work over multiple invocations of the
hash function.  
</t>
<t>
  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 <xref target="Fluhrer17" />
  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).
</t>
<t>
The reason this size was 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.
</t>
<t>
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.
</t>

<!--t>
The largest possible value of C(S), where S is an n-byte string,
can be computed as follows.
There are n/w terms in S used to compute the sum, and the maximum value
of each term is 2^w - 1, so the maximum value of C(S) is (2^w - 1) * (n/w) = (2^w -
1)*(8/w)*hash_len.  This number can be expressed using the same number
of bits used to express n, or the same number of bits needed to
express 8*hash_len.
</t-->
<t>
The Checksum <xref target="ldwm_msg_chksum"/> 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 <xref
target='ldwm_sig_gen' /> 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 <xref target="ldwm_params"/> and
calculated in <xref target='ldwm_param_opts' />, which indicates the
number of bits used in the left-shift operation.
</t>

<!--
<t>
I is a constant 16 bytes; we do this so that the Winternitz chain operation
can be computed with a single hash function operation; for SHA-256, this
mandates that the value being hashed be no longer than 55 bytes.
</t>
<t>
A future version of this specification may support hash functions
other than SHA-256; the setting of I=16 bytes is believed to be appropriate
for every hash function that we expect to support.
</t>
-->


<section anchor="secstring" title="Security string">
<t>
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:
</t>
<t>
<list>
   <t> 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.
   </t>
   <t>
     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.
   </t>
   <t>
     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.
   </t>
   <t>
     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 the valeu being hashed, and takes on the following values:
       <list>
	 <t>
            D_PBLC = 0x8080 when computing the hash of all of the
            iterates in the LM-OTS algorithm
	 </t>
	 <t>
            D_MESG = 0x8181 when computing the hash of the message in
                     the LM-OTS algorithms
	 </t>
	 <t>
            D_LEAF = 0x8282 when computing the hash of the leaf of an LMS tree
	 </t>
	 <t>
            D_INTR = 0x8383 when computing the hash of an interior node
            of an LMS tree
	 </t>
         <t>
            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.
         </t>
       </list>
   </t>
   <t>
     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 D is a value between 0 and 264.
     If present, it occurs at byte 22 of the value being hashed.
   </t>
   <t>
     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.
   </t>
</list>
</t>
</section>

</section>

<section anchor="History" title="History">
<t>
This is the eleventh version of this draft.  It has the
following changes from previous versions:</t>
<t>Version 10</t>
<t><list>
  <t>
       Numerous clarifications and typo corrections.
  </t>
</list></t>
<t>Version 09</t>
<t><list>
  <t>
       Corrected size of the OTS signature in section 4.2
  </t>
  <t>
       Miscellaneous clarifications and typo corrections.
  </t>
</list></t><t>Version 08</t>
<t><list>
  <t>
       Added additional test vector with private key
  </t>
  <t>
       Added appendix with discussion of parameter set trade-offs
  </t>
  <t>
       Miscellaneous clarifications and typo corrections.
  </t>
</list></t>
<t>Version 07</t>
<t><list>
  <t>
        Corrected the LMS public key format specification in section 5.3;
        the format listed in section 7 was correct.
  </t>
  <t>
        Corrected the LMS public key generation algorithm in appendix C.
        The hashes listed in section 5.3 were correct.
  </t>
  <t>
        Corrected the HSS signature verification algorithm in section 6.3.
  </t>
  <t>
        Miscellaneous clarifications and typo corrections.
  </t>
</list></t>
<t>Version 06</t>
<t><list>
 <t>
         Modified the order of the values that were hashed to make it easier to prove security.
 </t>
 <t>
         Decreased the size of the I LMS public key identifier to 16 bytes.
 </t>
</list></t>
<t>Version 05</t>
<t><list>
 <t>
         Clarified the L=1 specific case.
 </t>
 <t>
         Extended the parameter sets to include an H=25 option
 </t>
 <t>
         A large number of corrections and clarifications
 </t>
 <t>
         Added a comparison to XMSS and SPHINCS, and citations to
         those algorithms and to the recent Security Standardization
         Research 2016 publications on the security of LMS and on the
         state management in hash-based signatures.
 </t>
</list></t>
<t>Version 04</t>
<t><list>
 <t>
         Specified that, in the HSS method, the I value was computed
         from the I value of the parent LM tree.  Previous versions
         had the I value extracted from the public key (which meant
         that all LM trees of a particular level and public key used
         the same I value)
 </t>
 <t>
         Changed the length of the I field based on the parameter set.
         As noted in the Rationale section, this allows an
         implementation to compute SHA256 n=32 based parameter sets
         significantly faster.
 </t>
 <t>
         Modified the XDR of an HSS signature not to use an array
         of LM signatures; LM signatures are variable length, and
         XDR doesn&apos;t support arrays of variable length structures.
 </t>
 <t>
         Changed the LMS registry to be in a consistent order with the
         LM-OTS parameter sets.  Also, added LMS parameter sets with
         height 15 trees
 </t>
</list></t>

<t>Previous versions</t>
<t><list>

<t>
  In Algorithms 3 and 4, the message was moved from the initial
  position of the input to the function H to the final position, in
  the computation of the intermediate variable Q.  This was done to
  improve security by preventing an attacker that can find a
  collision in H from taking advantage of that fact via the forward
  chaining property of Merkle-Damgard.
</t>
<t>
The Hierarchical Signature Scheme was generalized slightly so
that it can use more than two levels.  
</t>
<t>
Several points of confusion were corrected; these had resulted from
incomplete or inconsistent changes from the Merkle approach of the
earlier draft to the Leighton-Micali approach.
</t>
</list></t>
<t>
This section is to be removed by the RFC editor upon publication.
</t>
</section>

<section anchor="IANA" title="IANA Considerations">
<t>
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 Section 3, and one for Leighton-Micali
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:
 <list>
   <t>a short name, such as "LMS_SHA256_M32_H10",    </t>

   <t>a positive number, and</t>

   <t>a reference to a specification that completely defines the
   signature method test cases that can be used to verify the
   correctness of an implementation.</t>
 </list>
Requests to add an entry to the registry MUST include the name and the
reference.  The number is assigned by IANA. 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.
</t>

<t>
  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
  <xref target="RFC2434"/>.
</t>

<t>
The LM-OTS registry is as follows.
</t>

      <texttable anchor="iana_reg_ldwm">
        <ttcol align="left">Name</ttcol>

        <ttcol align="center">Reference</ttcol>

        <ttcol align="center">Numeric Identifier</ttcol>

        <c> LMOTS_SHA256_N32_W1 </c><c> <xref target="ldwm"/></c><c> 0x00000001 </c>
        <c> LMOTS_SHA256_N32_W2 </c><c> <xref target="ldwm"/></c><c> 0x00000002 </c>
        <c> LMOTS_SHA256_N32_W4 </c><c> <xref target="ldwm"/></c><c> 0x00000003 </c>
	<c> LMOTS_SHA256_N32_W8 </c><c> <xref target="ldwm"/></c><c> 0x00000004 </c>

      </texttable>

<t>
The LMS registry is as follows.
</t>

      <texttable anchor="iana_reg_mts">
        <ttcol align="left">Name</ttcol>

        <ttcol align="center">Reference</ttcol>

        <ttcol align="center">Numeric Identifier</ttcol>

        <c> LMS_SHA256_M32_H5</c><c>  <xref target="merkle"/></c><c> 0x00000005 </c>
        <c> LMS_SHA256_M32_H10</c><c> <xref target="merkle"/></c><c> 0x00000006 </c>
        <c> LMS_SHA256_M32_H15</c><c> <xref target="merkle"/></c><c> 0x00000007 </c>
        <c> LMS_SHA256_M32_H20</c><c> <xref target="merkle"/></c><c> 0x00000008 </c>
        <c> LMS_SHA256_M32_H25</c><c> <xref target="merkle"/></c><c> 0x00000009 </c>

      </texttable>

      <t>
        An IANA registration of a signature system does not constitute an
        endorsement of that system or its security.
        </t>

</section>

<section anchor="IP" title="Intellectual Property">
<t>
This draft is based on U.S. patent 5,432,852, which issued over twenty
years ago and is thus expired.  
</t>

<section title="Disclaimer">
<t>
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.
</t>

<t>
The IETF policies and processes regarding intellectual property and
patents are outlined in <xref target="RFC3979"/> and
<xref target="RFC4879"/> and at
https://datatracker.ietf.org/ipr/about.
</t>
</section>
</section>

<section anchor="Security" title="Security Considerations">
<t>
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').
</t>
<t>
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.
</t>
<t>
LMS is provably secure in the random oracle model, where the hash compression
function is considered the random oracle, as shown by <xref
target="Fluhrer17"/>.  Corollary 1 of that paper states:
<list>
  <t>
    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.
  </t>
</list>
</t>

<t> 
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.
</t>

<section title="Hash Formats">
<t>
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.
</t>
<figure>
<preamble>The formats used during
key generation and signing
</preamble>
<artwork>
   I || u32str(q) || u16str(i) || u8str(j) || tmp
   I || u32str(q) || u16str(D_PBLC) || y[0] || ... || y[p-1]
   I || u32str(q) || u16str(D_MESG) || C || message
   I || u32str(r) || u16str(D_LEAF) || OTS_PUB_HASH[r-2^h]
   I || u32str(r) || u16str(D_INTR) || T[2*r] || T[2*r+1]
   I || u32str(q) || u16str(j) || u8str(0xff) || SEED
</artwork>
</figure>
<t>
Each hash type listed is distinct; at locations 20, 21 of each
hash, there exists either a fixed value D_PBLC, D_MESG, D_LEAF,
D_INTR, or a 16 bit value (i or j).  These fixed values are
distinct from each other, and are large (over 32768), while the 16 bit
values are small (currently no more than 265; possibly being slightly
larger if larger hash functions are supported); hence the hash
invocations with i/j will not collide any of the D_PBLC, D_MESG,
D_LEAF, D_INTR hashes.  The only other collision possibility is
the Winternitz chain hash colliding with the recommended pseudorandom
key generation process; here, at location 22, 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.
</t>

<t>
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.
</t>

<t>
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 &lt; 2^-132),
and hence the number of repeats for any specific
prefix will be limited to 3.  This is shown (in <xref
target="Fluhrer17"/>) to have only a limited effect on the
security of the system.
</t>
</section>

<section title="Stateful signature algorithm" anchor="stateful">
<t>
  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.
</t>
<t>
  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.
</t>
<t>
  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.
</t>
</section>


<section title="Security of LM-OTS Checksum">
<t>
  To show the security of LM-OTS checksum, we consider the signature y of
  a message with a private key x and let h&nbsp;=&nbsp;H(message) and
  c&nbsp;=&nbsp;Cksm(H(message)) (see <xref target='ldwm_sig_gen' />).  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,
<list style="empty">
  <t>
   a' = coef(h', j, w),
  </t>
  <t>
   a = coef(h, j, w), and
  </t>
  <t>
   a' > a
  </t>
</list>
  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,
<list style="empty">
  <t>
   b' = coef(c', k, w),
  </t>
  <t>
   b = coef(c, k, w), and
  </t>
  <t>
   b' &lt; b
  </t>
</list>
Due to the one-way property of F, the attacker cannot easily compute F^b'(x[k])
from F^b(x[k]) = y[k].
</t>
</section>
<!--

<section title="Security Conjectures">
<t>
LM-OTS and LMS 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 LM-OTS and LMS, the security of the
hash function is sufficient.
</t>
</section>

<section title="Post-Quantum Security" anchor="pq">
<t>
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.
</t>
<t>
The LM-OTS and Merkle signature systems are post-quantum secure if they
are used with an appropriate underlying hash function.  In contrast,
the signature systems in wide use (RSA, DSA, and ECDSA) are not
post-quantum secure.
</t>
</section>
-->

</section>

<!--section anchor="params" title="Parameter Choices">
<t>
The parameters m and n are chosen to ensure an appropriate level of
security.  The value of p is determined by the choice of n.  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.
Parameter choices are reviewed below.
<artwork>
 Hash            w-bit                Number
Length         Elements     Left        of
(bytes)  w     in Count     Shift     Elements
  20     1         8          8         168
  20     2     4          8          84
  20     4     3          4          43
  20     8     2          0          22
  32     1     9          7         265
  32     2     5          6         133
  32     4     3          4          67
  32     8     2          0          34
  48     1     9          7         393
  48     2     5          6         197
  48     4     3          4          99
  48     8     2          0          50
  64     1    10          6         522
  64     2     5          6         261
  64     4     3          4         131
  64     8     2          0          66
</artwork-->
<!--
<artwork>
    lmax(w,t) = number of bits needed to encode Count
          t=160     t=256     t=384     t=512
   w=1      8          8        9          9
   w=2      8          9       10         10
   w=4     10         10       11         11
   w=8     13         13       14         14
</artwork>
<artwork>
    degree(w,t) = number of w-bit windows needed to encode Count
          t=160     t=256     t=384     t=512
   w=1      4          4        5          5
   w=2      4          5        5          5
   w=4      5          5        6          6
   w=8      7          7        7          7
</artwork>
<artwork>
    shift(w,t) = 16 - 2 * degree(w,t)
          t=160     t=256     t=384     t=512
   w=1      8          8        6          6
   w=2      8          6        6          6
   w=4      6          6        4          4
   w=8      4          4        4          4
</artwork>
-->
<!--/t>
</section-->

<section anchor="comparison" title="Comparison with other work">
<t>
The eXtended Merkle Signature Scheme (XMSS) <xref target="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.  
</t>
<t>
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).
</t>

<!--
<t>
The Winternitz operation is made of up of three subparts; these are:

- Generating the private preimage for each hash chain; both the
current XMS and LMSS operation perform one hash compression operation
to do this; it could be done a bit more efficiently (say, if you have
AES-NI), but we'll count it as a 1 for now.

- We iterate to the next item in the Winternitz chain.  For LMS, we do
this with 1 hash compression operation (precomputing the hash state
after hashing 'I').  For XMSS, they call their internal PRF function
twice (which uses 1 hash compression operation each with
precomputation), and their internal F function once (which takes 2
hash compression operations; precomputation being inapplication), for
a total of 4 operations.

- We then combine all the tops of the Winternitz chains into a single
hash.  LMS just takes all the tops, and just hashes them together in a
big block (with some extra); if D is the number of hash chains, then
we'll looking at about (D+1)/2 hash compression operations (as two
hashes fit in one hash block).  For XMSS, they use an "l-tree", where
there are D-1 internal nodes, and for each node, they do 3 PRF
functions (which, again, use 1 hash compression operation each), and
one H function (which takes 3 hash compression operations, given the
size of the value being hashed), giving a total of 6(D-1) hash
compression operations.

So, if the Winternitz parameter is W (XMSS notation, which is the number of message bits each digit covers, this is 2**W in LMS notation), then to do an OTS public key generation,

- LMS takes D + (W-1)D + (D+1)/2 = WD + D/2 + 1/2 hash compression
operations (with a ceiling or floor operation being inserted here; I'm
not sure which off-the-top)

- XMSS takes D + 4(W-1)D + 6(D-1) = 4WD + 3D - 6 hash compression
operations.

For typical values of W, D, (say, W=4 and D=67), this gives 302 vs
1267 hash compression operations, or about a 4x speed difference.

Looking at the OTS signature and verification operation gives similar
results.

This analysis assumes SHA-256 as our hash function (which both
supports), and it also assumes that the number of hash compression
operations is where the bulk of the time is spent (which
instrumentation of the two implementations have shown).

</t>
-->
</section>

<section anchor="Acknowledgements" title="Acknowledgements">
<t>
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 <xref
target="USPTO5432852"/> and Jonathan Katz, who gave us security
guidance, and Bruno Couillard and Jim Goodman for an especially thorough review.
</t>
</section>

  </middle>

  <back>

    <references title="Normative References">

      &rfc2119;

      &rfc2434;

      &rfc3979;

      &rfc4506;

      &rfc4879;

    <reference anchor="FIPS180">
        <front>
          <title>Secure Hash Standard (SHS)</title>
          <author>
            <organization>National Institute of Standards and Technology</organization>
          </author>
          <date month="March" year="2012"></date>
        </front>
        <seriesInfo name="FIPS" value="180-4"></seriesInfo>
      </reference>

    <reference anchor="USPTO5432852">
        <front>
          <title>Large provably fast and secure digital signature schemes from secure hash functions</title>
          <author surname="Leighton" initials="T.">
          </author>
          <author surname="Micali" initials="S.">
          </author>
          <date month="July" year="1995"></date>
        </front>
        <seriesInfo name="U.S. Patent" value="5,432,852"></seriesInfo>
      </reference>



    </references>

    <references title="Informative References">

      <reference anchor="Katz16">
        <front>
          <title>Analysis of a proposed hash-based signature standard</title>
          <author surname="Katz" initials="J.">
            <organization />
          </author>
          <date year="2016" />
        </front>
        <seriesInfo name="Security Standardization Research (SSR) Conference" 
		    value="http://www.cs.umd.edu/~jkatz/papers/HashBasedSigs-SSR16.pdf" />
      </reference>


      <reference anchor="Fluhrer17">
        <front>
          <title>Further analysis of a proposed hash-based signature standard</title>
          <author surname="Fluhrer" initials="S.">
            <organization />
          </author>
          <date year="2017" />
        </front>
        <seriesInfo name="EPrint" 
		    value="http://eprint.iacr.org/2017/553.pdf" />
      </reference>


    <reference anchor="XMSS">
        <front>
          <title>XMSS-a practical forward secure signature scheme based on minimal security assumptions.</title>
          <author surname="Buchmann" initials="J.">          </author>
          <author surname="Dahmen" initials="E.">       </author>
          <author surname="Andreas Huelsing">       </author>
          <date year="2011"></date>
        </front>
        <seriesInfo name="International Workshop on Post-Quantum Cryptography" value="Springer Berlin."></seriesInfo>
      </reference>

    <reference anchor="STMGMT">
        <front>
          <title>State Management for Hash-based Signatures.</title>
          <author surname="McGrew" initials="D.">       </author>
          <author surname="Fluhrer" initials="S.">       </author>
          <author surname="Kampanakis" initials="P.">       </author>
          <author surname="Gazdag" initials="S.">       </author>
          <author surname="Butin" initials="D.">       </author>
          <author surname="Buchmann" initials="J.">          </author>
          <date year="2016"></date>
        </front>
        <seriesInfo name="Security Standardization Resarch (SSR) Conference" value="224."></seriesInfo>
      </reference>

<!--
    <reference anchor="SPHINCS">
        <front>
          <title>SPHINCS: Practical Stateless Hash-Based Signatures.</title>
          <author surname="Bernstein" initials="D.">       </author>
          <author surname="Hopwood" initials="D.">       </author>
          <author surname="Hulsing" initials="A.">       </author>
          <author surname="Lange" initials="T.">       </author>
          <author surname="Niederhagen" initials="R.">       </author>
          <author surname="Papachristadoulou" initials="L.">       </author>
          <author surname="Schneider" initials="M.">       </author>
          <author surname="Schwabe" initials="P.">       </author>
          <author surname="Wilcox-O'Hearn" initials="Z.">       </author>
          <date year="2015"></date>
        </front>
        <seriesInfo name="Annual International Conference on the Theory and Applications of Cryptographic Techniques" value="Springer."></seriesInfo>
      </reference>
-->

      <reference anchor="Grover96">
        <front>
          <title>A fast quantum mechanical algorithm for database search</title>
          <author surname="Grover" initials="L.K.">
            <organization />
          </author>
          <date year="1996" />
        </front>
        <seriesInfo name="28th ACM Symposium on the Theory of Computing" value="p. 212" />
      </reference>

<!--
      <reference anchor="BDM08">
        <front>
          <title>
	    Hash-based Digital Signature Schemes
	  </title>
          <author surname="Buchmann" initials="J.">
            <organization />
          </author>
          <author surname="Dahmen" initials="E.">
            <organization />
          </author>
          <author surname="Szydlo" initials="M.">
            <organization />
          </author>
          <date year="2008" />
        </front>
        <seriesInfo name="Technische Universitat Darmstadt Technical Report" 
		    value="https://www.cdc.informatik.tu-darmstadt.de/~dahmen/papers/hashbasedcrypto.pdf" />
      </reference>

      <reference anchor="C:Dods05">
        <front>
          <title>Hash Based Digital Signature Schemes</title>
          <author surname="Dods" initials="C.">
            <organization />
          </author>
          <author surname="Smart" initials="N.P.">
            <organization />
          </author>
          <author surname="Stam" initials="M.">
            <organization />
          </author>
          <date year="2005" />
        </front>
        <seriesInfo name="Lecture Notes in Computer Science vol. 3796" value="Cryptography and Coding" />
      </reference>

-->

      <reference anchor="C:Merkle89a">
        <front>
          <title>A Certified Digital Signature</title>
          <author surname="Merkle" initials="R. C.">
            <organization />
          </author>
          <date year="1990" />
        </front>
        <seriesInfo name="Lecture Notes in Computer Science" value="crypto89vol" />
      </reference>

      <reference anchor="C:Merkle89b">
        <front>
          <title>One Way Hash Functions and DES</title>
          <author surname="Merkle" initials="R. C.">
            <organization />
          </author>
          <date year="1990" />
        </front>
        <seriesInfo name="Lecture Notes in Computer Science" value="crypto89vol" />
      </reference>

      <reference anchor="C:Merkle87">
        <front>
          <title>A Digital Signature Based on a Conventional Encryption Function</title>
          <author surname="Merkle" initials="R. C.">
            <organization />
          </author>
          <date year="1988" />
        </front>
        <seriesInfo name="Lecture Notes in Computer Science" value="crypto87vol" />
      </reference>


      <reference anchor="Merkle79">
        <front>
          <title>Secrecy, Authentication, and Public Key Systems</title>
          <author surname="Merkle" initials="R. C.">
            <organization />
          </author>
          <date year="1979" />
        </front>
        <seriesInfo name="Stanford University Information Systems Laboratory" value="Technical Report 1979-1" />
      </reference>

    </references>

<section anchor="PRG" title="Pseudorandom Key Generation">
<t>
An implementation MAY use the following pseudorandom process
for generating an LMS private key.  
<list>
  <t>
   SEED is an m-byte value that is generated uniformly 
   at random at the start of the process,
  </t>
  <t>
   I is LMS key pair identifier,
  </t>
  <t>
   q denotes the LMS leaf number of an LM-OTS private key,
  </t>
  <t>
   x_q denotes the x array of private elements in the LM-OTS private
   key with leaf number q,
  </t>
  <t>
   j is an index of the private key element, and
  </t>
  <t>
   H is the hash function used in LM-OTS.
  </t>
</list>
The elements of the LM-OTS private keys are computed as:
</t>
<figure>
<artwork>
x_q[j] = H(I || u32str(q) || u16str(j) || u8str(0xff) || SEED).
</artwork>
</figure>
<t>
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
<xref target="Fluhrer17" /> 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.
</t>
</section>

<section title='LM-OTS Parameter Options' anchor='ldwm_param_opts'>
<!-- might want to add a table showing example values of signature size vs. computational overhead -->
<t>
The LM-OTS one time signature method uses several internal parameters, which are a function of the selected parameter set.
These internal parameters set:
<list>
<t> 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)</t>
<t> ls - This is the size of the shift needed to move the checksum so that it appears in the checksum digits </t>
</list>

</t>

<figure>
<preamble>The parameters ls, and p are computed as follows:</preamble>
<artwork>
  u = ceil(8*n/w)
  v = ceil((floor(lg((2^w - 1) * u)) + 1) / w)
  ls = 16 - (v * w)
  p = u + v
</artwork>
<postamble>
Here u and v represent the number of w-bit fields required to contain the
hash of the message and the checksum byte strings, respectively. And
as the value of p is the number of w-bit elements of
(&nbsp;H(message)&nbsp;||&nbsp;Cksm(H(message))&nbsp;), it is also equivalently
the number of byte strings that form the private key and the number of byte
strings in the signature.
The value 16 in the ls computation of ls corresponds to the 16 bits value used for the sum variable in Algorithm 2 in <xref target='ldwm_msg_chksum' />
</postamble>
</figure>

<t>
A table illustrating various combinations of n and w with the associated values of
u, v, ls, and p is provided in
<xref target='tbl_ldwm_params' />.
</t>

<texttable anchor='tbl_ldwm_params'>
<ttcol align='center'>Hash Length in Bytes (n)</ttcol>
<ttcol align='center'>Winternitz Parameter (w)</ttcol>
<ttcol align='center'>w-bit Elements in Hash (u)</ttcol>
<ttcol align='center'>w-bit Elements in Checksum (v)</ttcol>
<ttcol align='center'>Left Shift (ls)</ttcol>
<ttcol align='center'>Total Number of w-bit Elements (p)</ttcol>
<c>32</c> <c>1</c> <c>256</c> <c>9</c>  <c>7</c> <c>265</c>
<c>32</c> <c>2</c> <c>128</c> <c>5</c>  <c>6</c> <c>133</c>
<c>32</c> <c>4</c> <c>64</c>  <c>3</c>  <c>4</c> <c>67</c>
<c>32</c> <c>8</c> <c>32</c>  <c>2</c>  <c>0</c> <c>34</c>
</texttable>
</section>

<section anchor="iterativeLMS" title="An iterative algorithm for computing an LMS public key">
<t>
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]).
</t>
<figure>
<preamble>Generating an LMS Public Key from an LMS Private Key</preamble>
<artwork>
  for ( i = 0; i &lt; 2^h; i = i + 1 ) {
    r = i + num_lmots_keys;
    temp = H(I || u32str(r) || u16str(D_LEAF) || OTS_PUB_HASH[i])
    j = i;
    while (j % 2 == 1) {
      r = (r - 1)/2;
      j = (j-1) / 2;
      left_side = pop(data stack);
      temp = H(I || u32str(r) || u16str(D_INTR) || left_side || temp)
    }
    push temp onto the data stack
 }
 public_key = pop(data stack)
</artwork>
<postamble>Note that this pseudocode expects that all 2^h leaves of
the tree have equal depth; that is, num_lmots_keys to be a power of 2.   The maximum depth of the stack will be h-1 elements, that is, a total of (h-1)*n bytes; for the currently defined parameter sets, this will never be more than 768 bytes of data. 
</postamble>
</figure>
</section>

<section anchor="deriveLMSPath" title="Method for deriving authentication path for a signature">
<t>
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:
</t>
<figure>
<preamble>Generating an LMS Signature</preamble>
<artwork>
  1. set type to the typecode of the LMS algorithm

  2. extract h from the typecode according to table 2

  3. create the LM-OTS signature for the message:
     ots_signature = lmots_sign(message, LMS_PRIV[q])

  4. compute the array path as follows:
     i = 0
     r = 2^h + q
     while (i &lt; h) {
         temp = (r / 2^i) xor 1
         path[i] = T[temp]
         i = i + 1
    }

  5. S = u32str(q) || ots_signature || u32str(type) || path[0] || path[1] || ... || path[h-1]

  6. q = q + 1

  7. return S
</artwork>
</figure>

<t>
where 'xor' is the bitwise exclusive-or operation, and / is integer division (that is, rounded down to an integer value)
</t>

</section>

<section title="Example Implementation" anchor="example">
<t>
An example implementation can be found online at http://github.com/cisco/hash-sigs.
</t>
</section>

<section title="Parameter Set Recommendations" anchor="parm_set_recommendations">
<t>
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.
</t>
<t>
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 I
  have does not have the SHA-256 extensions; you could possibly do
  significantly better.
<figure>
<artwork> 
    ParmSet  KeyGenTime  SigSize   KeyLifetime
     15         6 sec      1616     30 seconds
     20         3 min      1776     16 minutes
     25      1.5 hour      1936     9 hours
    15/10       6 sec      3172     9 hours
    15/15       6 sec      3332     12 days
    20/10       3 min      3332     12 days
    20/15       3 min      3492     1 year
    25/10    1.5 hour      3492     1 year
    25/15    1.5 hour      3652     34 years
</artwork>
</figure>
</t>
<t>ParmSet: this is the height of the Merkle tree(s); parameter sets listed as
      a single integer consists of a single Merkle tree of that height;
      parameter sets that consist of two trees are listed as x/y, with
      x being the height of the top level Merkle tree, and y being the
      bottom level.
</t>
<t>  KeyGenTime: the measured key generation time; that is, the time needed to generate the public private key pair.
</t>
<t>  SigSize: the size of a signature (in bytes)
</t>
<t>  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.
</t>
<t>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 maybe a factor of 8) by
  using a parameter set with W=4; however that also about doubles the
  signature size.
</t>
</section>

<section title="Test Cases">
<t>
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.
</t>
<figure>
<preamble>Test Case 1 Public Key</preamble>
<artwork>
--------------------------------------------
HSS public key
levels      00000002
--------------------------------------------
LMS type    00000005                         # LM_SHA256_M32_H5
LMOTS type  00000004                         # LMOTS_SHA256_N32_W8
I           61a5d57d37f5e46bfb7520806b07a1b8
K           50650e3b31fe4a773ea29a07f09cf2ea
            30e579f0df58ef8e298da0434cb2b878
--------------------------------------------
--------------------------------------------
</artwork>
</figure>
<figure>
<preamble>Test Case 1 Message</preamble>
<artwork>
--------------------------------------------
Message     54686520706f77657273206e6f742064  |The powers not d|
            656c65676174656420746f2074686520  |elegated to the |
            556e6974656420537461746573206279  |United States by|
            2074686520436f6e737469747574696f  | the Constitutio|
            6e2c206e6f722070726f686962697465  |n, nor prohibite|
            6420627920697420746f207468652053  |d by it to the S|
            74617465732c20617265207265736572  |tates, are reser|
            76656420746f20746865205374617465  |ved to the State|
            7320726573706563746976656c792c20  |s respectively, |
            6f7220746f207468652070656f706c65  |or to the people|
            2e0a                              |..|
--------------------------------------------
</artwork>
</figure>
<figure>
<preamble>Test Case 1 Signature</preamble>
<artwork>
--------------------------------------------
HSS signature
Nspk        00000001
sig[0]:
--------------------------------------------
LMS signature
q           00000005
--------------------------------------------
LMOTS signature
LMOTS type  00000004                         # LMOTS_SHA256_N32_W8
C           d32b56671d7eb98833c49b433c272586
            bc4a1c8a8970528ffa04b966f9426eb9
y[0]        965a25bfd37f196b9073f3d4a232feb6
            9128ec45146f86292f9dff9610a7bf95
y[1]        a64c7f60f6261a62043f86c70324b770
            7f5b4a8a6e19c114c7be866d488778a0
y[2]        e05fd5c6509a6e61d559cf1a77a970de
            927d60c70d3de31a7fa0100994e162a2
y[3]        582e8ff1b10cd99d4e8e413ef469559f
            7d7ed12c838342f9b9c96b83a4943d16
y[4]        81d84b15357ff48ca579f19f5e71f184
            66f2bbef4bf660c2518eb20de2f66e3b
y[5]        14784269d7d876f5d35d3fbfc7039a46
            2c716bb9f6891a7f41ad133e9e1f6d95
y[6]        60b960e7777c52f060492f2d7c660e14
            71e07e72655562035abc9a701b473ecb
y[7]        c3943c6b9c4f2405a3cb8bf8a691ca51
            d3f6ad2f428bab6f3a30f55dd9625563
y[8]        f0a75ee390e385e3ae0b906961ecf41a
            e073a0590c2eb6204f44831c26dd768c
y[9]        35b167b28ce8dc988a3748255230cef9
            9ebf14e730632f27414489808afab1d1
y[10]       e783ed04516de012498682212b078105
            79b250365941bcc98142da13609e9768
y[11]       aaf65de7620dabec29eb82a17fde35af
            15ad238c73f81bdb8dec2fc0e7f93270
y[12]       1099762b37f43c4a3c20010a3d72e2f6
            06be108d310e639f09ce7286800d9ef8
y[13]       a1a40281cc5a7ea98d2adc7c7400c2fe
            5a101552df4e3cccfd0cbf2ddf5dc677
y[14]       9cbbc68fee0c3efe4ec22b83a2caa3e4
            8e0809a0a750b73ccdcf3c79e6580c15
y[15]       4f8a58f7f24335eec5c5eb5e0cf01dcf
            4439424095fceb077f66ded5bec73b27
y[16]       c5b9f64a2a9af2f07c05e99e5cf80f00
            252e39db32f6c19674f190c9fbc506d8
y[17]       26857713afd2ca6bb85cd8c107347552
            f30575a5417816ab4db3f603f2df56fb
y[18]       c413e7d0acd8bdd81352b2471fc1bc4f
            1ef296fea1220403466b1afe78b94f7e
y[19]       cf7cc62fb92be14f18c2192384ebceaf
            8801afdf947f698ce9c6ceb696ed70e9
y[20]       e87b0144417e8d7baf25eb5f70f09f01
            6fc925b4db048ab8d8cb2a661ce3b57a
y[21]       da67571f5dd546fc22cb1f97e0ebd1a6
            5926b1234fd04f171cf469c76b884cf3
y[22]       115cce6f792cc84e36da58960c5f1d76
            0f32c12faef477e94c92eb75625b6a37
y[23]       1efc72d60ca5e908b3a7dd69fef02491
            50e3eebdfed39cbdc3ce9704882a2072
y[24]       c75e13527b7a581a556168783dc1e975
            45e31865ddc46b3c957835da252bb732
y[25]       8d3ee2062445dfb85ef8c35f8e1f3371
            af34023cef626e0af1e0bc017351aae2
y[26]       ab8f5c612ead0b729a1d059d02bfe18e
            fa971b7300e882360a93b025ff97e9e0
y[27]       eec0f3f3f13039a17f88b0cf808f4884
            31606cb13f9241f40f44e537d302c64a
y[28]       4f1f4ab949b9feefadcb71ab50ef27d6
            d6ca8510f150c85fb525bf25703df720
y[29]       9b6066f09c37280d59128d2f0f637c7d
            7d7fad4ed1c1ea04e628d221e3d8db77
y[30]       b7c878c9411cafc5071a34a00f4cf077
            38912753dfce48f07576f0d4f94f42c6
y[31]       d76f7ce973e9367095ba7e9a3649b7f4
            61d9f9ac1332a4d1044c96aefee67676
y[32]       401b64457c54d65fef6500c59cdfb69a
            f7b6dddfcb0f086278dd8ad0686078df
y[33]       b0f3f79cd893d314168648499898fbc0
            ced5f95b74e8ff14d735cdea968bee74
--------------------------------------------
LMS type    00000005                         # LM_SHA256_M32_H5
path[0]     d8b8112f9200a5e50c4a262165bd342c
            d800b8496810bc716277435ac376728d
path[1]     129ac6eda839a6f357b5a04387c5ce97
            382a78f2a4372917eefcbf93f63bb591
path[2]     12f5dbe400bd49e4501e859f885bf073
            6e90a509b30a26bfac8c17b5991c157e
path[3]     b5971115aa39efd8d564a6b90282c316
            8af2d30ef89d51bf14654510a12b8a14
path[4]     4cca1848cf7da59cc2b3d9d0692dd2a2
            0ba3863480e25b1b85ee860c62bf5136
--------------------------------------------
LMS public key
LMS type    00000005                         # LM_SHA256_M32_H5
LMOTS type  00000004                         # LMOTS_SHA256_N32_W8
I           d2f14ff6346af964569f7d6cb880a1b6
K           6c5004917da6eafe4d9ef6c6407b3db0
            e5485b122d9ebe15cda93cfec582d7ab
--------------------------------------------
final_signature:
--------------------------------------------
LMS signature
q           0000000a
--------------------------------------------
LMOTS signature
LMOTS type  00000004                         # LMOTS_SHA256_N32_W8
C           0703c491e7558b35011ece3592eaa5da
            4d918786771233e8353bc4f62323185c
y[0]        95cae05b899e35dffd71705470620998
            8ebfdf6e37960bb5c38d7657e8bffeef
y[1]        9bc042da4b4525650485c66d0ce19b31
            7587c6ba4bffcc428e25d08931e72dfb
y[2]        6a120c5612344258b85efdb7db1db9e1
            865a73caf96557eb39ed3e3f426933ac
y[3]        9eeddb03a1d2374af7bf771855774562
            37f9de2d60113c23f846df26fa942008
y[4]        a698994c0827d90e86d43e0df7f4bfcd
            b09b86a373b98288b7094ad81a0185ac
y[5]        100e4f2c5fc38c003c1ab6fea479eb2f
            5ebe48f584d7159b8ada03586e65ad9c
y[6]        969f6aecbfe44cf356888a7b15a3ff07
            4f771760b26f9c04884ee1faa329fbf4
y[7]        e61af23aee7fa5d4d9a5dfcf43c4c26c
            e8aea2ce8a2990d7ba7b57108b47dabf
y[8]        beadb2b25b3cacc1ac0cef346cbb90fb
            044beee4fac2603a442bdf7e507243b7
y[9]        319c9944b1586e899d431c7f91bcccc8
            690dbf59b28386b2315f3d36ef2eaa3c
y[10]       f30b2b51f48b71b003dfb08249484201
            043f65f5a3ef6bbd61ddfee81aca9ce6
y[11]       0081262a00000480dcbc9a3da6fbef5c
            1c0a55e48a0e729f9184fcb1407c3152
y[12]       9db268f6fe50032a363c9801306837fa
            fabdf957fd97eafc80dbd165e435d0e2
y[13]       dfd836a28b354023924b6fb7e48bc0b3
            ed95eea64c2d402f4d734c8dc26f3ac5
y[14]       91825daef01eae3c38e3328d00a77dc6
            57034f287ccb0f0e1c9a7cbdc828f627
y[15]       205e4737b84b58376551d44c12c3c215
            c812a0970789c83de51d6ad787271963
y[16]       327f0a5fbb6b5907dec02c9a90934af5
            a1c63b72c82653605d1dcce51596b3c2
y[17]       b45696689f2eb382007497557692caac
            4d57b5de9f5569bc2ad0137fd47fb47e
y[18]       664fcb6db4971f5b3e07aceda9ac130e
            9f38182de994cff192ec0e82fd6d4cb7
y[19]       f3fe00812589b7a7ce51544045643301
            6b84a59bec6619a1c6c0b37dd1450ed4
y[20]       f2d8b584410ceda8025f5d2d8dd0d217
            6fc1cf2cc06fa8c82bed4d944e71339e
y[21]       ce780fd025bd41ec34ebff9d4270a322
            4e019fcb444474d482fd2dbe75efb203
y[22]       89cc10cd600abb54c47ede93e08c114e
            db04117d714dc1d525e11bed8756192f
y[23]       929d15462b939ff3f52f2252da2ed64d
            8fae88818b1efa2c7b08c8794fb1b214
y[24]       aa233db3162833141ea4383f1a6f120b
            e1db82ce3630b3429114463157a64e91
y[25]       234d475e2f79cbf05e4db6a9407d72c6
            bff7d1198b5c4d6aad2831db61274993
y[26]       715a0182c7dc8089e32c8531deed4f74
            31c07c02195eba2ef91efb5613c37af7
y[27]       ae0c066babc69369700e1dd26eddc0d2
            16c781d56e4ce47e3303fa73007ff7b9
y[28]       49ef23be2aa4dbf25206fe45c20dd888
            395b2526391a724996a44156beac8082
y[29]       12858792bf8e74cba49dee5e8812e019
            da87454bff9e847ed83db07af3137430
y[30]       82f880a278f682c2bd0ad6887cb59f65
            2e155987d61bbf6a88d36ee93b6072e6
y[31]       656d9ccbaae3d655852e38deb3a2dcf8
            058dc9fb6f2ab3d3b3539eb77b248a66
y[32]       1091d05eb6e2f297774fe6053598457c
            c61908318de4b826f0fc86d4bb117d33
y[33]       e865aa805009cc2918d9c2f840c4da43
            a703ad9f5b5806163d7161696b5a0adc
--------------------------------------------
LMS type    00000005                         # LM_SHA256_M32_H5
path[0]     d5c0d1bebb06048ed6fe2ef2c6cef305
            b3ed633941ebc8b3bec9738754cddd60
path[1]     e1920ada52f43d055b5031cee6192520
            d6a5115514851ce7fd448d4a39fae2ab
path[2]     2335b525f484e9b40d6a4a969394843b
            dcf6d14c48e8015e08ab92662c05c6e9
path[3]     f90b65a7a6201689999f32bfd368e5e3
            ec9cb70ac7b8399003f175c40885081a
path[4]     09ab3034911fe125631051df0408b394
            6b0bde790911e8978ba07dd56c73e7ee
</artwork>
</figure>

<figure>
<preamble>Test Case 2 Private Key</preamble>
<artwork>
--------------------------------------------
(note: procedure in Appendix A is used)
SEED        000102030405060708090a0b0c0d0e0f
            101112131415161718191a1b1c1d1e1f
I           d08fabd4a2091ff0a8cb4ed834e74534
--------------------------------------------
--------------------------------------------
</artwork>
</figure>
<figure>
<preamble>Test Case 2 Public Key</preamble>
<artwork>
--------------------------------------------
HSS public key
levels      00000002
--------------------------------------------
LMS type    00000006                         # LM_SHA256_M32_H10
LMOTS type  00000003                         # LMOTS_SHA256_N32_W4
I           d08fabd4a2091ff0a8cb4ed834e74534
K           32a58885cd9ba0431235466bff9651c6
            c92124404d45fa53cf161c28f1ad5a8e
--------------------------------------------
--------------------------------------------
</artwork>
</figure>
<figure>
<preamble>Test Case 2 Message</preamble>
<artwork>
--------------------------------------------
Message     54686520656e756d65726174696f6e20 The enumeration 
            696e2074686520436f6e737469747574 in the Constitut
            696f6e2c206f66206365727461696e20 ion, of certain 
            7269676874732c207368616c6c206e6f rights, shall no
            7420626520636f6e7374727565642074 t be construed t
            6f2064656e79206f7220646973706172 o deny or dispar
            616765206f7468657273207265746169 age others retai
            6e6564206279207468652070656f706c ned by the peopl
            652e0a                           e..
--------------------------------------------
</artwork>
</figure>
<figure>
<preamble>Test Case 2 Signature</preamble>
<artwork>
--------------------------------------------
HSS signature
Nspk        00000001
sig[0]:
--------------------------------------------
LMS signature
q           00000003
--------------------------------------------
LMOTS signature
LMOTS type  00000003                         # LMOTS_SHA256_N32_W4
C           3d46bee8660f8f215d3f96408a7a64cf
            1c4da02b63a55f62c666ef5707a914ce
y[0]        0674e8cb7a55f0c48d484f31f3aa4af9
            719a74f22cf823b94431d01c926e2a76
y[1]        bb71226d279700ec81c9e95fb11a0d10
            d065279a5796e265ae17737c44eb8c59
y[2]        4508e126a9a7870bf4360820bdeb9a01
            d9693779e416828e75bddd7d8c70d50a
y[3]        0ac8ba39810909d445f44cb5bb58de73
            7e60cb4345302786ef2c6b14af212ca1
y[4]        9edeaa3bfcfe8baa6621ce88480df237
            1dd37add732c9de4ea2ce0dffa53c926
y[5]        49a18d39a50788f4652987f226a1d481
            68205df6ae7c58e049a25d4907edc1aa
y[6]        90da8aa5e5f7671773e941d805536021
            5c6b60dd35463cf2240a9c06d694e9cb
y[7]        54e7b1e1bf494d0d1a28c0d31acc7516
            1f4f485dfd3cb9578e836ec2dc722f37
y[8]        ed30872e07f2b8bd0374eb57d22c614e
            09150f6c0d8774a39a6e168211035dc5
y[9]        2988ab46eaca9ec597fb18b4936e66ef
            2f0df26e8d1e34da28cbb3af75231372
y[10]       0c7b345434f72d65314328bbb030d0f0
            f6d5e47b28ea91008fb11b05017705a8
y[11]       be3b2adb83c60a54f9d1d1b2f476f9e3
            93eb5695203d2ba6ad815e6a111ea293
y[12]       dcc21033f9453d49c8e5a6387f588b1e
            a4f706217c151e05f55a6eb7997be09d
y[13]       56a326a32f9cba1fbe1c07bb49fa04ce
            cf9df1a1b815483c75d7a27cc88ad1b1
y[14]       238e5ea986b53e087045723ce16187ed
            a22e33b2c70709e53251025abde89396
y[15]       45fc8c0693e97763928f00b2e3c75af3
            942d8ddaee81b59a6f1f67efda0ef81d
y[16]       11873b59137f67800b35e81b01563d18
            7c4a1575a1acb92d087b517a8833383f
y[17]       05d357ef4678de0c57ff9f1b2da61dfd
            e5d88318bcdde4d9061cc75c2de3cd47
y[18]       40dd7739ca3ef66f1930026f47d9ebaa
            713b07176f76f953e1c2e7f8f271a6ca
y[19]       375dbfb83d719b1635a7d8a138919579
            44b1c29bb101913e166e11bd5f34186f
y[20]       a6c0a555c9026b256a6860f4866bd6d0
            b5bf90627086c6149133f8282ce6c9b3
y[21]       622442443d5eca959d6c14ca8389d12c
            4068b503e4e3c39b635bea245d9d05a2
y[22]       558f249c9661c0427d2e489ca5b5dde2
            20a90333f4862aec793223c781997da9
y[23]       8266c12c50ea28b2c438e7a379eb106e
            ca0c7fd6006e9bf612f3ea0a454ba3bd
y[24]       b76e8027992e60de01e9094fddeb3349
            883914fb17a9621ab929d970d101e45f
y[25]       8278c14b032bcab02bd15692d21b6c5c
            204abbf077d465553bd6eda645e6c306
y[26]       5d33b10d518a61e15ed0f092c3222628
            1a29c8a0f50cde0a8c66236e29c2f310
y[27]       a375cebda1dc6bb9a1a01dae6c7aba8e
            bedc6371a7d52aacb955f83bd6e4f84d
y[28]       2949dcc198fb77c7e5cdf6040b0f84fa
            f82808bf985577f0a2acf2ec7ed7c0b0
y[29]       ae8a270e951743ff23e0b2dd12e9c3c8
            28fb5598a22461af94d568f29240ba28
y[30]       20c4591f71c088f96e095dd98beae456
            579ebbba36f6d9ca2613d1c26eee4d8c
y[31]       73217ac5962b5f3147b492e8831597fd
            89b64aa7fde82e1974d2f6779504dc21
y[32]       435eb3109350756b9fdabe1c6f368081
            bd40b27ebcb9819a75d7df8bb07bb05d
y[33]       b1bab705a4b7e37125186339464ad8fa
            aa4f052cc1272919fde3e025bb64aa8e
y[34]       0eb1fcbfcc25acb5f718ce4f7c2182fb
            393a1814b0e942490e52d3bca817b2b2
y[35]       6e90d4c9b0cc38608a6cef5eb153af08
            58acc867c9922aed43bb67d7b33acc51
y[36]       9313d28d41a5c6fe6cf3595dd5ee63f0
            a4c4065a083590b275788bee7ad875a7
y[37]       f88dd73720708c6c6c0ecf1f43bbaada
            e6f208557fdc07bd4ed91f88ce4c0de8
y[38]       42761c70c186bfdafafc444834bd3418
            be4253a71eaf41d718753ad07754ca3e
y[39]       ffd5960b0336981795721426803599ed
            5b2b7516920efcbe32ada4bcf6c73bd2
y[40]       9e3fa152d9adeca36020fdeeee1b7395
            21d3ea8c0da497003df1513897b0f547
y[41]       94a873670b8d93bcca2ae47e64424b74
            23e1f078d9554bb5232cc6de8aae9b83
y[42]       fa5b9510beb39ccf4b4e1d9c0f19d5e1
            7f58e5b8705d9a6837a7d9bf99cd1338
y[43]       7af256a8491671f1f2f22af253bcff54
            b673199bdb7d05d81064ef05f80f0153
y[44]       d0be7919684b23da8d42ff3effdb7ca0
            985033f389181f47659138003d712b5e
y[45]       c0a614d31cc7487f52de8664916af79c
            98456b2c94a8038083db55391e347586
y[46]       2250274a1de2584fec975fb09536792c
            fbfcf6192856cc76eb5b13dc4709e2f7
y[47]       301ddff26ec1b23de2d188c999166c74
            e1e14bbc15f457cf4e471ae13dcbdd9c
y[48]       50f4d646fc6278e8fe7eb6cb5c94100f
            a870187380b777ed19d7868fd8ca7ceb
y[49]       7fa7d5cc861c5bdac98e7495eb0a2cee
            c1924ae979f44c5390ebedddc65d6ec1
y[50]       1287d978b8df064219bc5679f7d7b264
            a76ff272b2ac9f2f7cfc9fdcfb6a5142
y[51]       8240027afd9d52a79b647c90c2709e06
            0ed70f87299dd798d68f4fadd3da6c51
y[52]       d839f851f98f67840b964ebe73f8cec4
            1572538ec6bc131034ca2894eb736b3b
y[53]       da93d9f5f6fa6f6c0f03ce43362b8414
            940355fb54d3dfdd03633ae108f3de3e
y[54]       bc85a3ff51efeea3bc2cf27e1658f178
            9ee612c83d0f5fd56f7cd071930e2946
y[55]       beeecaa04dccea9f97786001475e0294
            bc2852f62eb5d39bb9fbeef75916efe4
y[56]       4a662ecae37ede27e9d6eadfdeb8f8b2
            b2dbccbf96fa6dbaf7321fb0e701f4d4
y[57]       29c2f4dcd153a2742574126e5eaccc77
            686acf6e3ee48f423766e0fc466810a9
y[58]       05ff5453ec99897b56bc55dd49b99114
            2f65043f2d744eeb935ba7f4ef23cf80
y[59]       cc5a8a335d3619d781e7454826df720e
            ec82e06034c44699b5f0c44a8787752e
y[60]       057fa3419b5bb0e25d30981e41cb1361
            322dba8f69931cf42fad3f3bce6ded5b
y[61]       8bfc3d20a2148861b2afc14562ddd27f
            12897abf0685288dcc5c4982f8260268
y[62]       46a24bf77e383c7aacab1ab692b29ed8
            c018a65f3dc2b87ff619a633c41b4fad
y[63]       b1c78725c1f8f922f6009787b1964247
            df0136b1bc614ab575c59a16d089917b
y[64]       d4a8b6f04d95c581279a139be09fcf6e
            98a470a0bceca191fce476f9370021cb
y[65]       c05518a7efd35d89d8577c990a5e1996
            1ba16203c959c91829ba7497cffcbb4b
y[66]       294546454fa5388a23a22e805a5ca35f
            956598848bda678615fec28afd5da61a
--------------------------------------------
LMS type    00000006                         # LM_SHA256_M32_H10
path[0]     b326493313053ced3876db9d23714818
            1b7173bc7d042cefb4dbe94d2e58cd21
path[1]     a769db4657a103279ba8ef3a629ca84e
            e836172a9c50e51f45581741cf808315
path[2]     0b491cb4ecbbabec128e7c81a46e62a6
            7b57640a0a78be1cbf7dd9d419a10cd8
path[3]     686d16621a80816bfdb5bdc56211d72c
            a70b81f1117d129529a7570cf79cf52a
path[4]     7028a48538ecdd3b38d3d5d62d262465
            95c4fb73a525a5ed2c30524ebb1d8cc8
path[5]     2e0c19bc4977c6898ff95fd3d310b0ba
            e71696cef93c6a552456bf96e9d075e3
path[6]     83bb7543c675842bafbfc7cdb88483b3
            276c29d4f0a341c2d406e40d4653b7e4
path[7]     d045851acf6a0a0ea9c710b805cced46
            35ee8c107362f0fc8d80c14d0ac49c51
path[8]     6703d26d14752f34c1c0d2c4247581c1
            8c2cf4de48e9ce949be7c888e9caebe4
path[9]     a415e291fd107d21dc1f084b11582082
            49f28f4f7c7e931ba7b3bd0d824a4570
--------------------------------------------
LMS public key
LMS type    00000005                         # LM_SHA256_M32_H5
LMOTS type  00000004                         # LMOTS_SHA256_N32_W8
I           215f83b7ccb9acbcd08db97b0d04dc2b
K           a1cd035833e0e90059603f26e07ad2aa
            d152338e7a5e5984bcd5f7bb4eba40b7
--------------------------------------------
final_signature:
--------------------------------------------
LMS signature
q           00000004
--------------------------------------------
LMOTS signature
LMOTS type  00000004                         # LMOTS_SHA256_N32_W8
C           0eb1ed54a2460d512388cad533138d24
            0534e97b1e82d33bd927d201dfc24ebb
y[0]        11b3649023696f85150b189e50c00e98
            850ac343a77b3638319c347d7310269d
y[1]        3b7714fa406b8c35b021d54d4fdada7b
            9ce5d4ba5b06719e72aaf58c5aae7aca
y[2]        057aa0e2e74e7dcfd17a0823429db629
            65b7d563c57b4cec942cc865e29c1dad
y[3]        83cac8b4d61aacc457f336e6a10b6632
            3f5887bf3523dfcadee158503bfaa89d
y[4]        c6bf59daa82afd2b5ebb2a9ca6572a60
            67cee7c327e9039b3b6ea6a1edc7fdc3
y[5]        df927aade10c1c9f2d5ff446450d2a39
            98d0f9f6202b5e07c3f97d2458c69d3c
y[6]        8190643978d7a7f4d64e97e3f1c4a08a
            7c5bc03fd55682c017e2907eab07e5bb
y[7]        2f190143475a6043d5e6d5263471f4ee
            cf6e2575fbc6ff37edfa249d6cda1a09
y[8]        f797fd5a3cd53a066700f45863f04b6c
            8a58cfd341241e002d0d2c0217472bf1
y[9]        8b636ae547c1771368d9f317835c9b0e
            f430b3df4034f6af00d0da44f4af7800
y[10]       bc7a5cf8a5abdb12dc718b559b74cab9
            090e33cc58a955300981c420c4da8ffd
y[11]       67df540890a062fe40dba8b2c1c548ce
            d22473219c534911d48ccaabfb71bc71
y[12]       862f4a24ebd376d288fd4e6fb06ed870
            5787c5fedc813cd2697e5b1aac1ced45
y[13]       767b14ce88409eaebb601a93559aae89
            3e143d1c395bc326da821d79a9ed41dc
y[14]       fbe549147f71c092f4f3ac522b5cc572
            90706650487bae9bb5671ecc9ccc2ce5
y[15]       1ead87ac01985268521222fb9057df7e
            d41810b5ef0d4f7cc67368c90f573b1a
y[16]       c2ce956c365ed38e893ce7b2fae15d36
            85a3df2fa3d4cc098fa57dd60d2c9754
y[17]       a8ade980ad0f93f6787075c3f680a2ba
            1936a8c61d1af52ab7e21f416be09d2a
y[18]       8d64c3d3d8582968c2839902229f85ae
            e297e717c094c8df4a23bb5db658dd37
y[19]       7bf0f4ff3ffd8fba5e383a48574802ed
            545bbe7a6b4753533353d73706067640
y[20]       135a7ce517279cd683039747d218647c
            86e097b0daa2872d54b8f3e508598762
y[21]       9547b830d8118161b65079fe7bc59a99
            e9c3c7380e3e70b7138fe5d9be255150
y[22]       2b698d09ae193972f27d40f38dea264a
            0126e637d74ae4c92a6249fa103436d3
y[23]       eb0d4029ac712bfc7a5eacbdd7518d6d
            4fe903a5ae65527cd65bb0d4e9925ca2
y[24]       4fd7214dc617c150544e423f450c99ce
            51ac8005d33acd74f1bed3b17b7266a4
y[25]       a3bb86da7eba80b101e15cb79de9a207
            852cf91249ef480619ff2af8cabca831
y[26]       25d1faa94cbb0a03a906f683b3f47a97
            c871fd513e510a7a25f283b196075778
y[27]       496152a91c2bf9da76ebe089f4654877
            f2d586ae7149c406e663eadeb2b5c7e8
y[28]       2429b9e8cb4834c83464f079995332e4
            b3c8f5a72bb4b8c6f74b0d45dc6c1f79
y[29]       952c0b7420df525e37c15377b5f09843
            19c3993921e5ccd97e097592064530d3
y[30]       3de3afad5733cbe7703c5296263f7734
            2efbf5a04755b0b3c997c4328463e84c
y[31]       aa2de3ffdcd297baaaacd7ae646e44b5
            c0f16044df38fabd296a47b3a838a913
y[32]       982fb2e370c078edb042c84db34ce36b
            46ccb76460a690cc86c302457dd1cde1
y[33]       97ec8075e82b393d542075134e2a17ee
            70a5e187075d03ae3c853cff60729ba4
--------------------------------------------
LMS type    00000005                         # LM_SHA256_M32_H5
path[0]     4de1f6965bdabc676c5a4dc7c35f97f8
            2cb0e31c68d04f1dad96314ff09e6b3d
path[1]     e96aeee300d1f68bf1bca9fc58e40323
            36cd819aaf578744e50d1357a0e42867
path[2]     04d341aa0a337b19fe4bc43c2e79964d
            4f351089f2e0e41c7c43ae0d49e7f404
path[3]     b0f75be80ea3af098c9752420a8ac0ea
            2bbb1f4eeba05238aef0d8ce63f0c6e5
path[4]     e4041d95398a6f7f3e0ee97cc1591849
            d4ed236338b147abde9f51ef9fd4e1c1
</artwork>
</figure>
</section>


<!--
<section title="Example Data for Testing" anchor="testing">
<t>
As with all criticism's, 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.
</t>
<section title='Parameters' anchor='test_params'>
<t>
The example contained in this section demonstrates the calculations of LMOTS_SHA256_M20_W4
using a Merkle Tree Signature of degree 4 and height 2. This corresponds to the following
parameter values:
</t>
<texttable anchor='tbl_test_params'>
<ttcol align='center'>m</ttcol>
<ttcol align='center'>n</ttcol>
<ttcol align='center'>w</ttcol>
<ttcol align='center'>p</ttcol>
<ttcol align='center'>ls</ttcol>
<ttcol align='center'>k</ttcol>
<ttcol align='center'>h</ttcol>
<c>20</c> <c>32</c> <c>4</c> <c>67</c> <c>4</c> <c>4</c> <c>2</c>
</texttable>
<t>
The non-standard size of the Merkle tree (h = 2) has been selected specifically
for this example to reduce the amount of data presented.
</t>
</section>
<section title='Key Generation' anchor='test_key_gen'>
<t>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.
</t>
<t>
For the test data presented here, a summary of the key generation method is as follows:
<list style='numbers'>
<t>MTS Private Key - Set mts_private_key to a pseudorandomly generated n-byte value.</t>
<t>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 <xref target='ldwm_prv_key' /> for each
leaf of the Merkle tree.</t>
<t>OTS Public Keys - For each OTS private key, calculate the corresponding OTS public key
as in Algorithm 1 of <xref target='ldwm_pub_key' />.</t>
<t>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 <xref target='mts_alg' /> or some equivalent implementation.</t>
</list>
</t>
<t>
The above steps result in the following data values associated with the first leaf of the
Merkle tree, leaf 0.
</t>
<texttable anchor='tbl_mts_priv_key'>
<ttcol align='center'>MTS Private Key</ttcol>
<c>0x0f677ff1b4cbf10baec89959f051f203 &nbsp;&nbsp;3371492da02f62dd61d6fbd1cee1bd14</c>
</texttable>
<texttable anchor='tbl_ots_priv_key'>
<ttcol align='center'>Key Element Index (i)</ttcol>
<ttcol align='center'>OTS Private Key 0 Element (x[i])</ttcol>
<c>0</c>  <c>0xbfb757383fb08d324629115a84daf00b &nbsp;&nbsp;188d5695303c83c184e1ec7a501c431f</c>
<c>1</c>  <c>0x7ce628fb82003a2829aab708432787d0 &nbsp;&nbsp;fc735a29d671c7d790068b453dc8c913</c>
<c>2</c>  <c>0x8174929461329d15068a4645a34412bd &nbsp;&nbsp;446d4c9e757463a7d5164efd50e05c93</c>
<c>3</c>  <c>0xf283f3480df668de4daa74bb0e4c5531 &nbsp;&nbsp;5bc00f7d008bb6311e59a5bbca910fd7</c>
<c>4</c>  <c>0xe62708eaf9c13801622563780302a068 &nbsp;&nbsp;0ba9d39c078daa5ebc3160e1d80a1ea7</c>
<c>5</c>  <c>0x1f002efad2bfb4275e376af7138129e3 &nbsp;&nbsp;3e88cf7512ec1dcdc7df8d5270bc0fd7</c>
<c>6</c>  <c>0x8ed5a703e9200658d18bc4c05dd0ca8a &nbsp;&nbsp;356448a26f3f4fe4e0418b52bd6750a2</c>
<c>7</c>  <c>0xc74e56d61450c5387e86ddad5a8121c8 &nbsp;&nbsp;8b1bc463e64f248a1f1d91d950957726</c>
<c>8</c>  <c>0x629f18b6a2a4ea65fff4cf758b57333f &nbsp;&nbsp;e1d34af05b1cd7763696899c9869595f</c>
<c>9</c>  <c>0x1741c31fdbb4864712f6b17fadc05d45 &nbsp;&nbsp;926c831c7a755b7d7af57ac316ba6c2a</c>
<c>10</c> <c>0xe59a7b81490c5d1333a9cdd48b9cb364 &nbsp;&nbsp;56821517a3a13cb7a8ed381d4d5f3545</c>
<c>11</c> <c>0x3ba97fe8b2967dd74c8b10f31fc5f527 &nbsp;&nbsp;a23b89c1266202a4d7c281e1f41fa020</c>
<c>12</c> <c>0xa262a9287cc979aaa59225d75df51b82 &nbsp;&nbsp;57b92e780d1ab14c4ac3ecdac58f1280</c>
<c>13</c> <c>0x9dfe0af1a3d9064338d96cb8eae88baa &nbsp;&nbsp;6a69265538873b4c17265fa9d573bcff</c>
<c>14</c> <c>0xde9c5c6a5c6a274eabe90ed2a8e6148c &nbsp;&nbsp;720196d237a839aaf5868af8da4d0829</c>
<c>15</c> <c>0x5de81ec17090a82cb722f616362d3808 &nbsp;&nbsp;30f04841191e44f1f81b9880164b14cd</c>
<c>16</c> <c>0xc0d047000604105bad657d9fa2f9ef10 &nbsp;&nbsp;1cfd9490f4668b700d738f2fa9e1d11a</c>
<c>17</c> <c>0xf45297ef310941e1e855f97968129bb1 &nbsp;&nbsp;73379193919f7b0fee9c037ae507c2d2</c>
<c>18</c> <c>0x46ef43a877f023e5e66bbcd4f06b839f &nbsp;&nbsp;3bfb2b64de25cd67d1946b0711989129</c>
<c>19</c> <c>0x46e2a599861bd9e8722ad1b55b8f0139 &nbsp;&nbsp;305fcf8b6077d545d4488c4bcb652f29</c>
<c>20</c> <c>0xe1ad4d2d296971e4b0b7a57de305779e &nbsp;&nbsp;82319587b58d3ef4daeb08f630bd5684</c>
<c>21</c> <c>0x7a07fa7aed97cb54ae420a0e6a58a153 &nbsp;&nbsp;38110f7743cab8353371f8ca710a4409</c>
<c>22</c> <c>0x40601f6c4b35362dd4948d5687b5cb6b &nbsp;&nbsp;5ec8b2ec59c2f06fd50f8919ebeaae92</c>
<c>23</c> <c>0xa061b0ba9f493c4991be5cd3a9d15360 &nbsp;&nbsp;a9eb94f6f7adc28dddf174074f3df3c4</c>
<c>24</c> <c>0xcf1546a814ff16099cebf1fe0db1ace5 &nbsp;&nbsp;1c272fda9846fbb535815924b0077fa4</c>
<c>25</c> <c>0xcbb06f13155ce4e56c85a32661c90142 &nbsp;&nbsp;8b630a4c37ea5c7062156f07f6b3efff</c>
<c>26</c> <c>0x1181ee7fc03342415094e36191eb450a &nbsp;&nbsp;11cdea9c6f6cdc34de79cee0ba5bf230</c>
<c>27</c> <c>0xe9f1d429b343bb897881d2a19ef363cd &nbsp;&nbsp;1ab4117cbaad54dc292b74b8af9f5cf2</c>
<c>28</c> <c>0x87f34b2551ef542f579fa65535c5036f &nbsp;&nbsp;80eb83be4c898266ffc531da2e1a9122</c>
<c>29</c> <c>0x9b4b467852fe33a03a872572707342fd &nbsp;&nbsp;ddeae64841225186babf353fa2a0cd09</c>
<c>30</c> <c>0x19d58cd240ab5c80be6ddf5f60d18159 &nbsp;&nbsp;2dca2be40118c1fdd46e0f14dffbcc7d</c>
<c>31</c> <c>0x5c9ad386547ba82939e49c9c74a8eccf &nbsp;&nbsp;1cea60aa327b5d2d0a66b1ca48912d6d</c>
<c>32</c> <c>0xf49083e502400ffae9273c6de92a301e &nbsp;&nbsp;7bda1537cab085e5adfa9eb746e8eca9</c>
<c>33</c> <c>0x4074e1812d69543ce3c1ce706f6e0b45 &nbsp;&nbsp;f5f26f4ef39b34caa709335fd71e8fc0</c>
<c>34</c> <c>0x1256612b0ca8398e97b247ae564b74b1 &nbsp;&nbsp;3839b3b1cf0a0dd8ba629a2c58355f84</c>
<c>35</c> <c>0xbab3989f00fd2c327bbfb35a218cc3ce &nbsp;&nbsp;49d6b34cbf8b6e8919e90c4eff400ca9</c>
<c>36</c> <c>0x96b52a5d395a5615b73dae65586ac5c8 &nbsp;&nbsp;7f9dd3b9b3f82dbf509b5881f0643fa8</c>
<c>37</c> <c>0x5d05ca4c644e1c41ccdaedbd2415d4f0 &nbsp;&nbsp;9b4a1b940b51fe823dff7617b8ee8304</c>
<c>38</c> <c>0xd96aab95ef6248e235d91d0f23b64727 &nbsp;&nbsp;a6675adfc64efea72f6f8b4a47996c0d</c>
<c>39</c> <c>0xfd9c384d52d3ac27c4f4898fcc15e83a &nbsp;&nbsp;c182f97ea63f7d489283e2cc7e6ed180</c>
<c>40</c> <c>0xc86eaed6a9e3fbe5b262c1fa1f099f7c &nbsp;&nbsp;35ece71d9e467fab7a371dbcf400b544</c>
<c>41</c> <c>0xf462b3719a2ed8778155638ff814dbf4 &nbsp;&nbsp;2b107bb5246ee3dd82abf97787e6a69e</c>
<c>42</c> <c>0x014670912e3eb74936ebb64168b447e4 &nbsp;&nbsp;2522b57c2540ac4b49b9ae356c01eca6</c>
<c>43</c> <c>0x2b411096e0ca16587830d3acd673e858 &nbsp;&nbsp;863fedc4cea046587cba0556d2bf9884</c>
<c>44</c> <c>0xa73917c74730582e8e1815b8a07b1896 &nbsp;&nbsp;2ac05e500e045676be3f1495fcfa18ca</c>
<c>45</c> <c>0xa4ab61e6962fe39a255dbf8a46d25110 &nbsp;&nbsp;0d127fab08db59512653607bda24302c</c>
<c>46</c> <c>0x9b910ca516413f376b9eba4b0d571b22 &nbsp;&nbsp;253c2a9646131ac9a2af5f615f7322b8</c>
<c>47</c> <c>0xfc1b4ce627c77ad35a21ea9ded2cce91 &nbsp;&nbsp;b3758a758224e35cf2918153a513d64c</c>
<c>48</c> <c>0xc1902d8e8c02d9442581d7e053a2798a &nbsp;&nbsp;a84d77a74b6e7f2cc5096d50646c890f</c>
<c>49</c> <c>0xb3f47e2e8e2dcdd890ea00934b9d8234 &nbsp;&nbsp;830dbc4a30ac996b144f12b3e463c77f</c>
<c>50</c> <c>0x8188d1ecfc6ae6118911f2b9b3a6c7a1 &nbsp;&nbsp;e5f909aa8b5c0aab8c69f1a7d436c307</c>
<c>51</c> <c>0xca42d985974c7b870bc76494604eff49 &nbsp;&nbsp;2676c942c6cb7c75d4938805885dd054</c>
<c>52</c> <c>0xbe58851ebe566057e1ee16b8c604a473 &nbsp;&nbsp;4c373af622660b2a82357ac6effb4566</c>
<c>53</c> <c>0xc22d493f7a5642fceba2404dbefa8f95 &nbsp;&nbsp;6323fac87fac425f6de8d23c9e8b20ca</c>
<c>54</c> <c>0x1a76c1ffa467906173fd0245b0cd6639 &nbsp;&nbsp;e6013ca79c4ed92426ee69ff5beeac0b</c>
<c>55</c> <c>0xbc6c0cb7808f379af1b7b7327436ad65 &nbsp;&nbsp;c05458f2d0a6923c333e5129c4c99671</c>
<c>56</c> <c>0xfbb04488c3c088dc5e63d13e6a701036 &nbsp;&nbsp;6109ca4c5f4b0a8d37780187e2e9930e</c>
<c>57</c> <c>0xaec10811569d4d72e3a1baf71a886b75 &nbsp;&nbsp;eba6dc07ed027af0b2beffa71f9b43c8</c>
<c>58</c> <c>0xf5529be3b7a19212e8baa970d2420bf4 &nbsp;&nbsp;123f678267f96c1c3ef26ab610cb0061</c>
<c>59</c> <c>0x172ba1ba0b701eeafe00692d1eb90181 &nbsp;&nbsp;8ccaefaeb8f799395da81711766d1f43</c>
<c>60</c> <c>0xfe1f8c15825208f3a21346b894b3d94e &nbsp;&nbsp;4f3aa29cbc194a7b2c8a810c4c509042</c>
<c>61</c> <c>0x2e81c66cc914ea1b0fa5942fe9780d54 &nbsp;&nbsp;8c0b330e3bf73f0cb0bda4bc9c9e6ff4</c>
<c>62</c> <c>0xfc3453aec5cc19a6a4bda4bc25931604 &nbsp;&nbsp;704bf4386cd65780c6e73214c1da85ba</c>
<c>63</c> <c>0x4e8000c587dc917888e7e3d817672c0a &nbsp;&nbsp;ef812788cc8579afa7e9b2e566309003</c>
<c>64</c> <c>0xba667ca0e44a8601a0fde825d4d2cf1b &nbsp;&nbsp;b9cf467041e04af84c9d0cd9fd8dc784</c>
<c>65</c> <c>0x4965db75f81c8a596680753ce70a94c6 &nbsp;&nbsp;156253bb426947de1d7662dd7e05e9a8</c>
<c>66</c> <c>0x2c23cc3e5ca37dec279c506101a3d8d9 &nbsp;&nbsp;f1e4f99b2a33741b59f8bddba7455419</c>
</texttable>
<t>
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
<xref target='tbl_sha_256_20' />.
</t>
<texttable anchor='tbl_ots_pub_key'>
<ttcol align='center'>OTS Public Key 0</ttcol>
<c>0x2db55a72075fcfab5aedbef77bf6b371 &nbsp;&nbsp;dfb489d6e61ad2884a248345e6910618</c>
</texttable>
<t>
Following the creation of all OTS public/private key pairs, the OTS public keys in
<xref target='tbl_ots_pub_keys' /> are used to determine the MTS public key below. Intermediate
values of the interior nodes of the Merkle tree are provided in <xref target='tbl_mts_int_nodes' />.
</t>
<texttable anchor='tbl_mts_pub_key'>
<ttcol align='center'>MTS Public Key</ttcol>
<c>0x6610803d9a3546fb0a7895f6a4a0cfed &nbsp;&nbsp;3a07d45e51d096e204b018e677453235</c>
</texttable>
</section>
<section title='Signature Generation' anchor='test_sig_gen'>
<t>
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.
</t>
<texttable anchor='tbl_hex_msg'>
<ttcol align='center'>Hexadecimal Byte Values</ttcol>
<ttcol align='center'>ASCII Representation ('.'&nbsp;is&nbsp;substituted for non-printing&nbsp;characters)</ttcol>
<c>0x48 0x65 0x6c 0x6c 0x6f 0x20 0x77 0x6f 0x72 0x6c 0x64 0x21 0x0a</c> <c>Hello world!.</c>
</texttable>
<t>
The SHA256 hash of the text file is provided below.
</t>
<texttable anchor='tbl_sha_256_msg'>
<ttcol align='center'>SHA256 Hash of Signed File (H("Hello world!\n"))</ttcol>
<c>0x0ba904eae8773b70c75333db4de2f3ac &nbsp;&nbsp;45a8ad4ddba1b242f0b3cfc199391dd8</c>
</texttable>
<t>
This value was subsequently used in Algorithm 3 of <xref target='ldwm_sig_gen' /> to
create the one-time signature of the message. Algorithm 2 of
<xref target='ldwm_msg_chksum' /> was applied to calculate a checksum of 0x1cc. The
resulting signature is shown in the following table.
</t>
<texttable anchor='tbl_ots'>
<ttcol align='center'>OTS Element Index (i)</ttcol>
<ttcol align='center'>Function Iteration Count (a&nbsp;=&nbsp;coef( H(msg) || C(H(msg)), i, w ))</ttcol>
<ttcol align='center'>OTS Element (y[i] = F^a(x[i]))</ttcol>
<c>0</c>  <c>0</c>  <c>0xbfb757383fb08d324629115a84daf00b188d5695</c>
<c>1</c>  <c>11</c> <c>0x4af079e885ddfd3245f29778d265e868a3bfeaa4</c>
<c>2</c>  <c>10</c> <c>0xfbad1928bfc57b22bcd949192452293d07d6b9ad</c>
<c>3</c>  <c>9</c>  <c>0xb98063e184b4cb949a51e1bb76d99d4249c0b448</c>
<c>4</c>  <c>0</c>  <c>0xe62708eaf9c13801622563780302a0680ba9d39c</c>
<c>5</c>  <c>4</c>  <c>0x39343cba3ffa6d75074ce89831b3f3436108318c</c>
<c>6</c>  <c>14</c> <c>0xfe08aa73607aec5664188a9dacdc34a295588c9a</c>
<c>7</c>  <c>10</c> <c>0xd3346382119552d1ceb92a78597a00c956372bf0</c>
<c>8</c>  <c>14</c> <c>0xf1dd245ec587c0a7a1b754cc327b27c839a6e46a</c>
<c>9</c>  <c>8</c>  <c>0xa5f158adc1decaf0c1edc1a3a5d8958d726627b5</c>
<c>10</c> <c>7</c>  <c>0x06d2990f62f22f0c943a418473678e3ffdbff482</c>
<c>11</c> <c>7</c>  <c>0xf3390b8d6e5229ae9c5d4c3f45e10455d8241a49</c>
<c>12</c> <c>3</c>  <c>0x22dd5f9d3c89180caa0f695203d8cf90f3c359be</c>
<c>13</c> <c>11</c> <c>0x67999c4043f95de5f07d82b741347a3eb6ac0c25</c>
<c>14</c> <c>7</c>  <c>0xc4ffe472d48adeb37c7360da70711462013b7a4e</c>
<c>15</c> <c>0</c>  <c>0x5de81ec17090a82cb722f616362d380830f04841</c>
<c>16</c> <c>12</c> <c>0x2f892c824af65cc749f912a36dfa8ade2e4c3fd1</c>
<c>17</c> <c>7</c>  <c>0xb644393e8030924403b594fb5cacd8b2d28862e2</c>
<c>18</c> <c>5</c>  <c>0x31b8d2908911dbbf5ba1f479a854808945d9e948</c>
<c>19</c> <c>3</c>  <c>0xa9a02269d24eb8fed6fb86101cbd0d8977219fb1</c>
<c>20</c> <c>3</c>  <c>0xe4aae6e6a9fe1b0d5099513f170c111dee95714d</c>
<c>21</c> <c>3</c>  <c>0xd79c16e7f2d4dd790e28bab0d562298c864e31e9</c>
<c>22</c> <c>13</c> <c>0xc29678f0bb4744597e04156f532646c98a0b42e8</c>
<c>23</c> <c>11</c> <c>0x57b31d75743ff0f9bcf2db39d9b6224110b8d27b</c>
<c>24</c> <c>4</c>  <c>0x0a336d93aac081a2d849c612368b8cbb2fa9563a</c>
<c>25</c> <c>13</c> <c>0x917be0c94770a7bb12713a4bae801fb3c1c43002</c>
<c>26</c> <c>14</c> <c>0x91586feaadcf691b6cb07c16c8a2ed0884666e84</c>
<c>27</c> <c>2</c>  <c>0xdd4e4b720fb2517c4bc6f91ccb8725118e5770c6</c>
<c>28</c> <c>15</c> <c>0x491f6ec665f54c4b3cffaa02ec594d31e6e26c0e</c>
<c>29</c> <c>3</c>  <c>0x4f5a082c9d9c9714701de0bf426e9f893484618c</c>
<c>30</c> <c>10</c> <c>0x11f7017313f0c9549c5d415a8abc25243028514d</c>
<c>31</c> <c>12</c> <c>0x6839a994fccb9cb76241d809146906a3d13f89f1</c>
<c>32</c> <c>4</c>  <c>0x71cd1d9163d7cd563936837c61d97bb1a5337cc0</c>
<c>33</c> <c>5</c>  <c>0x77c9034ffc0f9219841aa8e1edbfb62017ef9fd1</c>
<c>34</c> <c>10</c> <c>0xad9f6034017d35c338ac35778dd6c4c1abe4472a</c>
<c>35</c> <c>8</c>  <c>0x4a1c396b22e4f5cc2428045b36d13737c4007515</c>
<c>36</c> <c>10</c> <c>0x98cb57b779c5fd3f361cd5debc243303ae5baefd</c>
<c>37</c> <c>13</c> <c>0x29857298f274d6bf595eadc89e5464ccf9608a6c</c>
<c>38</c> <c>4</c>  <c>0x95e35a26815a3ae9ad84a24464b174a29364da18</c>
<c>39</c> <c>13</c> <c>0x4afeb3b95b5b333759c0acdd96ce3f26314bb22b</c>
<c>40</c> <c>13</c> <c>0x325a37ee5e349b22b13b54b24be5145344e7b8f3</c>
<c>41</c> <c>11</c> <c>0x4f772c93f56fd6958ce135f02847996c67e1f2ef</c>
<c>42</c> <c>10</c> <c>0xd4f6d91c577594060be328b013c9e9b0e8a2e5d8</c>
<c>43</c> <c>1</c>  <c>0x717e1a81c325cdccacb6e9fd9e92dd3e1bb84ae8</c>
<c>44</c> <c>11</c> <c>0x1dd363724ec66c090a1228dfa1cd3d9cc806f346</c>
<c>45</c> <c>2</c>  <c>0x64b4110476dd0beea78714c5ab71278818792cfa</c>
<c>46</c> <c>4</c>  <c>0xe22290e740056a144af50f0b10962b5bcc18fc82</c>
<c>47</c> <c>2</c>  <c>0x34fd87046a183f4732a52bb7805ce207eebdafc5</c>
<c>48</c> <c>15</c> <c>0xbd2fdc5e4e8d0ed7c48c1bad9c2f7793fc2c9303</c>
<c>49</c> <c>0</c>  <c>0xb3f47e2e8e2dcdd890ea00934b9d8234830dbc4a</c>
<c>50</c> <c>11</c> <c>0xcd29719c56cdb507030e6132132179e5807e1d3b</c>
<c>51</c> <c>3</c>  <c>0xf9edb9b301916217de0d746a0542316bebe9e806</c>
<c>52</c> <c>12</c> <c>0x7a3801cbfe0cafed863d81210c1ec721eede49e5</c>
<c>53</c> <c>15</c> <c>0x5caba3ec960efa210f5f3e1c22c567ca475ef3ec</c>
<c>54</c> <c>12</c> <c>0xf911b5d148e1b03fe6983c53411f76ea78772379</c>
<c>55</c> <c>1</c>  <c>0x06da2baa75c6ef752bf59f3812fa042ff8181209</c>
<c>56</c> <c>9</c>  <c>0x2b29f5aa2f34af51a78a5fac586004f749c6e6dc</c>
<c>57</c> <c>9</c>  <c>0x55e033ababac0845cc9142e24f9ef0a641c51cbe</c>
<c>58</c> <c>3</c>  <c>0xb62d207bb700071fba8a68312ca204ce4d994c33</c>
<c>59</c> <c>9</c>  <c>0x551d5c00fad905bdb99c4f70ec7590a10d3ff8ca</c>
<c>60</c> <c>1</c>  <c>0x0d03b1845b5f8838d735142f185f9cf8f8d2db6c</c>
<c>61</c> <c>13</c> <c>0x3b5d9e49e7ede41cd9aa5a09f72a0384fd4ff511</c>
<c>62</c> <c>13</c> <c>0xa766b0278d14a9b7d32bf0307c0737a8ecf82ab1</c>
<c>63</c> <c>8</c>  <c>0xca85296f354e6e3d2a96ab497c01e5ccd4530cf1</c>
<c>64</c> <c>1</c>  <c>0x7bb29db7dd8aaaf1cd11487cea0d13730edb1df3</c>
<c>65</c> <c>12</c> <c>0x547ef341b3cf3208753bb1b62d85a4e3fc2cffe0</c>
<c>66</c> <c>12</c> <c>0xb890e1a99da4b2e0a9dde42f82f92d0946327cee</c>
</texttable>
<t>
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
<xref target='mts_sig' />. These values are marked with
an asterisk ('*') in <xref target='tbl_ots_pub_keys' /> and <xref target='tbl_mts_int_nodes' />.
</t>
</section>
<section title='Signature Verification' anchor='test_sig_vrf'>
<t>
The signature verification step was provided the following items:
<list style='numbers'>
<t>OTS = (y[0] || y[1] || ... || y[p-1]) - from <xref target='tbl_ots' />.</t>
<t>Authentication Path = concatenation of (k-1)*h Merkle tree node values -
from <xref target='tbl_ots_pub_keys' /> and <xref target='tbl_mts_int_nodes' />.</t>
<t>Message Number = leaf number of Merkle tree.</t>
<t>Merkle Public Key = root of Merkle tree - from <xref target='tbl_mts_pub_key' />.</t>
</list>
Using Algorithm 4 of <xref target='ldwmn_sig_vrf' /> 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 <xref target='mts_sig_vrf' /> 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.
</t>
</section>
<section title='Intermediate Calculation Values'>
<texttable anchor='tbl_sha_256_20'>
<ttcol align='center'>Key Element Index (i)</ttcol>
<ttcol align='center'>SHA256-20 Result for w = 4 (F^15(x[i]))</ttcol>
<c>0</c>  <c>0x6eff4b0c224874ecc4e4f4500da53dbe2a030e45</c>
<c>1</c>  <c>0x58ac2c6c451c7779d67efefdb12e5c3d85475a94</c>
<c>2</c>  <c>0xb1f3e42e29c710d69268eed1bbdb7f5a500b7937</c>
<c>3</c>  <c>0x51d28e573aac2b84d659abb961c32c465e911b55</c>
<c>4</c>  <c>0xa0ed62bccac5888f5000ca6a01e5ffefd442a1c6</c>
<c>5</c>  <c>0x44da9e145666322422c1e2b5e21627e05aeb4367</c>
<c>6</c>  <c>0x04e7ff9213c2655f28364f659c35d3086d7414e1</c>
<c>7</c>  <c>0x414cdb3215408b9722a02577eeb71f9e016e4251</c>
<c>8</c>  <c>0xa3ab06b90a2b20f631175daa9454365a4f408e9e</c>
<c>9</c>  <c>0xe38acfd3c0a03faa82a0f4aeac1a7c04983fad25</c>
<c>10</c> <c>0xd95a289094ccce8ad9ff1d5f9e38297f9bb306ff</c>
<c>11</c> <c>0x593d148b22e33c32f18b66340bdaffceb3ad1a55</c>
<c>12</c> <c>0x16b53fbea11dc7ab70c8336ec3c23881ae5d51bf</c>
<c>13</c> <c>0xa639ca0cf871188cadd0020832c4f06e6ebd5f98</c>
<c>14</c> <c>0xe3ab3e0c5ad79d6c8c2a7e9a79856d4380941fe0</c>
<c>15</c> <c>0x8368c2933dabcde69c373867a9bf2dc78df97bea</c>
<c>16</c> <c>0xe3609fca11545da156a7779ae565b1e3c87902c0</c>
<c>17</c> <c>0xab029e62c7011772dc0589d79fad01aacf8d2177</c>
<c>18</c> <c>0xa8310f1c27c1aa481192de07d4397b8c4716e25f</c>
<c>19</c> <c>0xdbdbb14dbd9a5f03c1849af24b69b9e3f80faca2</c>
<c>20</c> <c>0x1a17399d555dec07d3d4f6d54b2b87d2bcaa398b</c>
<c>21</c> <c>0xf81c66cc522bfb203232e44d0003ed65d2462867</c>
<c>22</c> <c>0x202a625b8c5f22de6ea081af6da077cf5c63202f</c>
<c>23</c> <c>0x2e080f3591f5ff3d5de39c2698846cc107a09816</c>
<c>24</c> <c>0xa1d9c78c22f9810e3b7db2d59ad9f5fdd259f4d4</c>
<c>25</c> <c>0x658eeb85ebe0f4542c4d32dced2d7226929266b2</c>
<c>26</c> <c>0x67fae1a784f919577afc091504d82d31b4ba9fc7</c>
<c>27</c> <c>0xfc39fb43677fb2d433a6292f19c6e7320279655a</c>
<c>28</c> <c>0x491f6ec665f54c4b3cffaa02ec594d31e6e26c0e</c>
<c>29</c> <c>0x17cec813a5781409b11d2e4a85f62301c2fd8873</c>
<c>30</c> <c>0xc578eb105454d900c053eb55833db607aa5757e0</c>
<c>31</c> <c>0xaed094323290a41fd4b546919620e2f6b23916c8</c>
<c>32</c> <c>0x192b5a87b5124dc287e06cdd4ec7c0c11f67dda6</c>
<c>33</c> <c>0x4e9e2bdc1b0204d1ceeb68fb4159e752c40b9608</c>
<c>34</c> <c>0xf34c57ad9ce45d67fd32dc2737e6263bcc5cc61f</c>
<c>35</c> <c>0xf73bd27d376186310f83cc66e72060aeaccde371</c>
<c>36</c> <c>0xeea482511acd8be783e9be42b48799653b222db4</c>
<c>37</c> <c>0xa2e53196fec8676065b8f32b3e8498e66a4af3cf</c>
<c>38</c> <c>0x670c98185157e1b28d38f7dafb00796b434c8316</c>
<c>39</c> <c>0x441afbb265b93595389aaa66325de792f343f209</c>
<c>40</c> <c>0x7b6c50d20b5edc0bc90eb4b289770514cbc8d547</c>
<c>41</c> <c>0xfde6e862a7ba3534893a3e630e209a24be590b1e</c>
<c>42</c> <c>0xc59611200c20b2e73dfb24c84cedf4792d6daf10</c>
<c>43</c> <c>0x66e3527bee88373d18f91b230b53b569361f0a15</c>
<c>44</c> <c>0xd0fd79c7116198e689275fec9b4c46f4aac73293</c>
<c>45</c> <c>0x65f07406ad4241e7cf4174c5f284267292cdbc32</c>
<c>46</c> <c>0x7b1b5535d45f46542e2b876245b66ea83cde3d8f</c>
<c>47</c> <c>0x7a11620934eb0eb17e10e4a8bbd52aa4b020da0e</c>
<c>48</c> <c>0xbd2fdc5e4e8d0ed7c48c1bad9c2f7793fc2c9303</c>
<c>49</c> <c>0x00432602437252a0622a30676dbaaef3023328b9</c>
<c>50</c> <c>0x09a9c4b25034466a5acd7ff681af1c27e8f97577</c>
<c>51</c> <c>0x4b31481d52aa5e1a261064bbd87ea46479a6be23</c>
<c>52</c> <c>0xaca2ad4aa1264618ab633bf11cbca3cc8fa43091</c>
<c>53</c> <c>0x5caba3ec960efa210f5f3e1c22c567ca475ef3ec</c>
<c>54</c> <c>0x353e3ffcedfd9500141921cf2aebc2e111364dad</c>
<c>55</c> <c>0xe1c498c32169c869174ccf2f1e71e7202f45fba7</c>
<c>56</c> <c>0x5b8519a40d4305813936c7c00a96f5b4ceb603f1</c>
<c>57</c> <c>0x3b942ae6a6bd328d08804ade771a0775bb3ff8f8</c>
<c>58</c> <c>0x6f3be60ee1c34372599b8d634be72e168453bf10</c>
<c>59</c> <c>0xf700c70bac24db0aab1257940661f5b57da6e817</c>
<c>60</c> <c>0x85ccf60624b13663a290fa808c6bbecaf89523cd</c>
<c>61</c> <c>0xd049be55ab703c44f42167d5d9e939c830df960f</c>
<c>62</c> <c>0xd27a178ccc3b364c7e03d2266093a0d1dfdd9d51</c>
<c>63</c> <c>0xd73c53fdddbe196b9ab56fcc5c9a4a57ad868cd1</c>
<c>64</c> <c>0xb59a70a7372f0c121fa71727baaf6588eccec400</c>
<c>65</c> <c>0x9b5bf379f989f9a499799c12a3202db58b084eed</c>
<c>66</c> <c>0xccabf40f3c1dacf114b5e5f98a73103b4c1f9b55</c>
</texttable>
<texttable anchor='tbl_ots_pub_keys'>
<ttcol align='center'>MTS Leaf (Level 3) Node Number</ttcol>
<ttcol align='center'>OTS Public Key (H(x[0]&nbsp;||&nbsp;x[1]&nbsp;||&nbsp;...&nbsp;||&nbsp;x[p-1]))</ttcol>
<ttcol align='center'>Member of Authentication Path of Message&nbsp;0</ttcol>
<c>0</c>  <c>0x2db55a72075fcfab5aedbef77bf6b371 &nbsp;&nbsp;dfb489d6e61ad2884a248345e6910618</c> <c> </c>
<c>1</c>  <c>0x8c6c6a1215bfe7fda10b7754e73cd984 &nbsp;&nbsp;a64823b1ab9d5f50feda6b151c0fee6d</c> <c>*</c>
<c>2</c>  <c>0xc1fb91de68b3059c273e53596108ec7c &nbsp;&nbsp;f39923757597fe86439e91ce1c25fc84</c> <c>*</c>
<c>3</c>  <c>0x1b511189baee50251335695b74d67c40 &nbsp;&nbsp;5a04eddaa79158a9090cc7c3eb204cbf</c> <c>*</c>
<c>4</c>  <c>0xf3bcf088ccf9d00338b6c87e8f822da6 &nbsp;&nbsp;8ec471f88d1561193b3c017d20b3c971</c> <c> </c>
<c>5</c>  <c>0x40584c059e6cc72fb61f7bd1b9c28e73 &nbsp;&nbsp;c689551e6e7de6b0b9b730fab9237531</c> <c> </c>
<c>6</c>  <c>0x1b1d09de1ca16ca890036e018d7e73de &nbsp;&nbsp;b39b07de80c19dcc5e55a699f021d880</c> <c> </c>
<c>7</c>  <c>0x83a82632acaac5418716f4f357f5007f &nbsp;&nbsp;719d604525dbe1831c09a2ead9400a52</c> <c> </c>
<c>8</c>  <c>0xccb8b2a1d60f731b5f51910eb427e211 &nbsp;&nbsp;96090d5cd2a077f33968b425301e3fbd</c> <c> </c>
<c>9</c>  <c>0x616767ebf3c1f3ec662d8c57c630c6ae &nbsp;&nbsp;b31853fd40a18c3d831f5490610c1f16</c> <c> </c>
<c>10</c> <c>0x5a4b3e157b66327c75d7f01304d188e2 &nbsp;&nbsp;cecd1b6168240c11a01775d581b01fb6</c> <c> </c>
<c>11</c> <c>0xf25744b8a1c2184ba38521801bf4727c &nbsp;&nbsp;407b85eb5aef8884d8fbb1c12e2f6108</c> <c> </c>
<c>12</c> <c>0xaf8189f51874999162890f72e0ef25e6 &nbsp;&nbsp;f76b4ab94dc53569bdd66507f5ab0d8e</c> <c> </c>
<c>13</c> <c>0x96251e396756686645f35cd059da329f &nbsp;&nbsp;7083838d56c9ccacebbaf8486af18844</c> <c> </c>
<c>14</c> <c>0x773d5206e40065d3553c3c2ed2500122 &nbsp;&nbsp;e3ee6fd2c91f35a57f084dc839aab1fc</c> <c> </c>
<c>15</c> <c>0xcda7fae67ce2c3ed29ce426fdcd3f2a8 &nbsp;&nbsp;eb699e47a67a52f1c94e89726ffe97fa</c> <c> </c>
</texttable>
<texttable anchor='tbl_mts_int_nodes'>
<ttcol align='center'>MTS Interior (Level 2) Node Number</ttcol>
<ttcol align='center'>Node Value (H(child_0&nbsp;||&nbsp;child_1&nbsp;||&nbsp;...&nbsp;|| child_k-1))</ttcol>
<ttcol align='center'>Member of Authentication Path of Message&nbsp;0</ttcol>
<c>0</c>  <c>0xb6a310deb55ed48004133ece2aebb25e &nbsp;&nbsp;d74defb77ebd8d63c79a42b5b4191b0c</c> <c> </c>
<c>1</c>  <c>0x71a0c8b767ade2c97ebac069383e4dfb &nbsp;&nbsp;a1c06d5fd3f69a775711ea6470747664</c> <c>*</c>
<c>2</c>  <c>0x91109fa97662dc88ae63037391ac2650 &nbsp;&nbsp;f6c664ac2448b54800a1df748953af31</c> <c>*</c>
<c>3</c>  <c>0xd277fb8c89689525f90de567068d6c93 &nbsp;&nbsp;565df3588b97223276ef8e9495468996</c> <c>*</c>
</texttable>
</section>
</section>

-->

  </back>

</rfc>
