<?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-mcgrew-fundamental-ecc PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-mcgrew-fundamental-ecc-04.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-06">

  <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="March" year="2017"/>
    <!-- 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 relatively slow key generation.
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 at most one message
securely, but cannot securely sign more than one.  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 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. We denote the one-time signature scheme
incorporate in LMS as LM-OTS.  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.
<!-- 
<xref target="testing"/>
describes test considerations and contains test cases that can be used
to validate an implementation.  
-->
The IANA registry for these signature
systems is described in <xref target="IANA"/>.  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>
<list>
  <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 are valid.
  </t>
</list>
</t>
<t>
   A message/signature pair are 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 are 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.
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="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 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.  The following fields can appear in a security string:
</t>
<t>
<list>
   <t> I - an identifier for the LMS public/private key pair.  The
   length of this value varies based on the LMS parameter set and it
   MUST be chosen uniformly at random, or via a pseudorandom process,
   at the time that a key pair is generated, in order to ensure that
   it will be distinct from the identifier of any other LMS private
   key with probability close to one.
   </t>
   <t>
   D - a domain separation parameter, which is a single byte that
       takes on different values in the different algorithms in which
       H is invoked.  D takes on the following values:
       <list>
	 <t>
            D_ITER = 0x00 in the iterations of the LM-OTS algorithms
	 </t>
	 <t>
            D_PBLC = 0x01 when computing the hash of all of the
            iterates in the LM-OTS algorithm
	 </t>
	 <t>
            D_MESG = 0x02 when computing the hash of the message in
                     the LM-OTS algorithms
	 </t>
	 <t>
            D_LEAF = 0x03 when computing the hash of the leaf of an LMS tree
	 </t>
	 <t>
            D_INTR = 0x04 when computing the hash of an interior node
            of an LMS tree
	 </t>
         <t>
            D_PRG = 0x05 in the recommended pseudorandom process for
            generating LMS private keys
         </t>
       </list>
   </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.
   </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.
   </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.
   </t>
   <t>
     i - in the LM-OTS scheme, i is the index of
     the private key element upon which H is being applied.  It is
     represented as a 16-bit (two byte) unsigned integer in network
     byte order.
   </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.
   </t>
</list>
</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="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 diversification parameter q.  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 (number of 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 functions 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>
</section>
<section title='Parameter Sets' anchor='ldwm_methods'>
<t>
To fully describe a LM-OTS signature method, the parameters n and
w, the length LenS of the security string S, as well as the
function H, MUST be specified.  This section defines
several LM-OTS methods, each of which is identified by a
name.  The values for p and ls are provided as a convenience.
</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'>LenS</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>68</c> <c>265</c> <c>7</c> 
<c>LMOTS_SHA256_N32_W2</c> <c>SHA256</c>     <c>32</c> <c>2</c> <c>68</c> <c>133</c> <c>6</c> 
<c>LMOTS_SHA256_N32_W4</c> <c>SHA256</c>     <c>32</c> <c>4</c> <c>68</c> <c>67</c>  <c>4</c> 
<c>LMOTS_SHA256_N32_W8</c> <c>SHA256</c>     <c>32</c> <c>8</c> <c>68</c> <c>34</c>  <c>0</c> 
</texttable>
<t>
Here SHA256 denotes the NIST standard hash function <xref target="FIPS180"/>.  
</t>
<!--
Here, the security string S will contain a unique identifier I of length 64 bytes and a four byte value r which when instantiated in the LMS scheme described in Section 5 will represent an index of a leaf node.


SHA256-16 denotes the SHA256 hash function with
its final output truncated to return the leftmost 16 bytes; that is, immediately after computing the SHA256 hash, the 32 bit hash output is truncated to be the leftmost 16 bytes.
-->
</section>
<section title='Private Key' anchor='ldwm_prv_key'>
<t>
The LM-OTS private key consists of a typecode indicating the
particular LM-OTS algorithm, an array x[] containing p n-byte strings,
and a LenS-byte security string S.  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. set type to the typecode of the algorithm

  2. if no security string S has been provided as input, then set S to
     a LenS-byte string generated uniformly at random

  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) || S || 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 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 and S 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(S || tmp || u16str(i) || u8str(j) || D_ITER)
       }
       y[i] = tmp
     }
     K = H(S || y[0] || ... || y[p-1] || D_PBLC)

  5. return u32str(type) || S || 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   - 31 bytes (or 64 bytes for postquantum)
  q   - 4 bytes
  tmp - n=16 bytes (or 32 bytes for postquantum)
  i   - 2 bytes
  j   - 1 bytes
  D   - 1 bytes
  total - 55 bytes (needs to be <= 55 for sha256); 64+40 bytes postquantum

-->

</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.  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
randomizer C and the security string S to the message, then appending
D_MESG to the resulting string then computing its hash, 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>
<!--
<t>
The identifier string I and diversification string q form the security string S, and is the same S as in Section 4.4.

  The identifier string I and diversification string q are 
  the same as in <xref target="ldwm_pub_key"/>.
</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 and S from the private key

  4. set C to a uniformly random n-byte string 

  5. compute the array y as follows:
     Q = H(S || C || message || D_MESG )
     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(S || tmp || u16str(i) || u8str(j) || D_ITER)
       }
       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: when n=16, the number of bytes in 

   tmp || I || q || i || j || D_ITER

is 16+31+4+2+1+1 = 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.

For postquantum, the first 64 bytes of the hash is always the same,
and hence an implementation can just compute that intermediate hash state once.
Thereafter, each hash consists of 40 bytes; hence also using only a single
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, S, and K from the public key as follows:
     a. pubtype = strTou32(first 4 bytes of public key)
      
     b. if pubtype is not equal to sigtype, return INVALID

     c. if the public key is not exactly 4 + LenS + n bytes long, 
        return INVALID

     c. S = next LenS bytes of public key

     d. K = next n bytes of public key

  3. compute the public key candidate Kc from the signature,
     message, and the security string S 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 a Security String
S</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 Type, return INVALID

     c. set n and p according to the sigtype 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(S || C || message || D_MESG)
     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(S || tmp || u16str(i) || u8str(j) || D_ITER)
       }
       z[i] = tmp
     }
     Kc = H(S || z[0] || z[1] || ... || z[p-1] || D_PBLC) 

  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.  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 L has node
  number 2^L + 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 (number of levels - 1) in 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. H SHOULD be the same as in <xref
      target="ldwm_params"/>, but MAY be different.
    </t>
  </list>
There are 2^h leaves in the tree.  The hash function used within the
LMS system MUST be the same as the hash function used within the
LM-OTS system used to generate the leaves.  This is required because
both use the same I value, and hence must have the same length of I
value (and the length of the I value is dependent on the hash
function).
</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_H24</c> <c>SHA256</c> <c>32</c> <c>25</c>
</texttable>
</section>

<section anchor="mts_priv" title="LMS Private Key">
<t>
  An LMS private key consists 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 security string S = 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. compute the array OTS_PRIV[] as follows:
      for ( q = 0; q &lt; 2^h; q = q + 1) {
         S = I || q
         OTS_PRIV[q] = LM-OTS private key with security string S
       }

   3. 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>
</section>
<section anchor="mts_alg" title="LMS Public Key">
<t>
  An LMS public key is defined as follows, where we denote the public
  key associated with the i^th LM-OTS private key as OTS_PUB[i],
  with i ranging from 0 to (2^h)-1.  Each instance of an LMS
  public/private key pair is associated with a perfect 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 || OTS_PUB[r-2^h]  || u32str(r) || D_LEAF)    if r >= 2^h,
        \ H(I || T[2*r] || T[2*r+1] || u32str(r) || D_INTR) otherwise.        
</artwork>
</figure>
<t>
  The LMS public key is the string u32str(type) || I || T[1]. <xref
  target="ldwm_xdr"/> specifies the format of the type variable.
  The value I is the private key identifier (whose length is denoted by
  the parameter set), 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>
    a typecode indicating the particular LMS algorithm,
  </t>
  <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, and
  </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 u32str(q) ||
ots_signature || u32str(type) || path[0] || path[1] || ... ||
path[h-1]. <xref target="ldwm_xdr"/> specifies the typecode and
more formally defines the format.  The array of values contains
the siblings of the nodes on the path from the leaf to the root but does not contain the nodes on the path themselves.  The
array for a tree with height h will have h values.  The first
value is the sibling of the leaf, the next value is the sibling of the parent of the leaf, and so on up the path to the root.
</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.  
  </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.  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>
<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 four 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. if the public key is not exactly 4 + LenI + m bytes 
        long, return INVALID

     c. I = next LenI bytes of the public key

     d. T[1] = next m bytes of the public key

  6. compute the candidate LMS root value Tc from the signature,
     message, identifier and pubtype using Algorithm 6b.

  7. if Tc is equal to T[1], return VALID; otherwise, return INVALID
</artwork>
</figure>
<figure>
<preamble>Algorithm 6b: 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, ots_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. ots_signature = bytes 8 through 8 + n * (p + 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
 
  5. Kc = candidate public key computed by applying Algorithm 4b 
     to the signature ots_signature, the message, and the 
     security string S = I || q

  6. compute the candidate LMS root value Tc as follows:
     node_num = 2^h + q
     tmp = H(I || Kc || u32str(node_num) || D_LEAF)
     i = 0
     while (node_num > 1) {
       if (node_num is odd):
         tmp = H(I || path[i] || tmp || u32str(node_num/2) || D_INTR)
       else:
         tmp = H(I || tmp || path[i] || u32str(node_num/2) || D_INTR)
       node_num = node_num/2
       i = i + 1
     }
     Tc = tmp

  7. 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 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.  Leighton and Micali describe a scheme in which an
LMS public key is used to sign a second LMS public key, which is then
distributed along with the signatures generated with the second public
key <xref target="USPTO5432852"/>.  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, in which 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
one of its leaves.  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.
</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 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.
</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 is 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] and prv[0] do 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>
</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>
  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:

   L' = strTou32(first four bytes of S)
   if L' is not equal to the number of levels L in pub:
      return INVALID
   for (i = 0; i < L; i = i + 1) {
      siglist[i] = next LMS signature parsed from S
      publist[i] = next LMS public key parsed from S
   }
   siglist[L-1] = next LMS signature parsed from S

   key = pub
   for (i =0; i < L; 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[L-1])        
]]>
</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 ots_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 ots_signature switch (ots_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 hbs_algorithm_type {
  hbs_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 (hbs_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;
  ots_signature lmots_sig;               
  lms_path nodes;
};

struct lms_key_n32 {
  ots_algorithm_type ots_alg_type;
  opaque I[64];                    
  opaque K[32];                
};    

union hbs_public_key switch (hbs_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;
  hbs_public_key pub;
};

struct signed_public_key {
  hbs_signature sig;
  hbs_public_key pub;
}

struct hss_signature {
  signed_public_key signed_keys<7>;
  hbs_signature sig_of_message;
};]]>
</artwork>
</figure>
<t> 
Many of the objects 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>
<!--
<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       
        * hbs_algorithm_type
          lms_public_key_n   
             * ots_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    
             * ots_algorithm_type
             * I
             * value
     lms_private_key      
        * lms_algorithm_type
          lms_public_key_n    
             * ots_algorithm_type
             * I
             * value
]]>
</artwork>
</figure>
<figure>
<artwork>
<![CDATA[
hss_signature   
   * hss_algorithm_type
     lms_public_key
        * lms_algorithm_type
          lms_key_n   
             * ots_algorithm_type 
             * I
             * value
     lms_signature        
        ots_signature
           * ots_algorithm_type 
           * C
           * q
           * y[p]
        lms_path               
           * lms_algorithm_type
           * path[h]
     lms_signature        
        ots_signature
           * ots_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 and LMS 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 required to be distinct in order to
  improve security.  That distinctness ensures the uniqueness of the
  inputs to H across all of those public/private key pair instances,
  which is important for provable security in the random oracle model.
  The length of I is set at 31 or 64 bytes so that randomly chosen values of
  I will be distinct with probability at least 1 - 1/2^128 as long as
  there are 2^60 or fewer instances of LMS public/private key pairs.
</t>
<t>
The sizes of the parameters in the security string are such that the
hashes computed by both LM and LM-OTS start with a fixed 64-byte I
value.  The reason this size was selected was to allow an
implementation to compute the intermediate hash state after processing
I once (similar to the well-known optimization for HMAC), and hence
the majority of hashes computed during LM-OTS processing can be
performed using a single hash compression operation when using
SHA-256.  Other hash functions, which may be used in future
specifications, can use a similar strategy, as long as I is long
enough that it is very unlikely to repeat if chosen uniformly at
random.
</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>
We vary the size of I based on the parameter set; the reason we do so is to
minimize the number of hash compression function evaluations required.  For
N=32 parameter sets, the Winternitz chain evaluations (which are the bulk of
the effort) have 55 byte hash preimages, which allows a SHA-256 hash to be
done with a single hash compression operatin.  For N=64 parameter sets, we
have the 64 byte I at front; that means that every hash done for that LMS
tree will start with the same 64 bytes.  An implementation can take advantage
of this by computing the intermediate SHA-256 state after processing those
first 64 bytes; reducing the number of hash compression operations required
in the Winternitz chain to one.
</t>
<t>
A future version of this specification may support hash functions
other than SHA-256.
</t>
-->
</section>

<section title="History">
<t>
This is the fifth version of this draft.  It has the
following changes from previous versions:</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 and
signature that are valid with that public key (that is, the Signature
Verification algorithm applied to that signature and message and
public key will return VALID).  Such an attacker, in the strongest
case, may have the ability to forge valid signatures for an arbitrary
number of other messages.
</t>
<t>
LMS is provably secure in the random oracle model, as shown by Katz
<xref target="Katz16"/>.  From Theorem 2 of
that reference:
<list>
  <t>
    For any adversary attacking the LMS scheme and making at most q
    hash queries, the probability the adversary forges a signature is
    at most 3*q/2^(8*n).
  </t>
</list>
Here n is the number of bytes in the output of the hash function (as
defined in <xref target="ldwm_params"/>).  The security of all of the
the algorithms and parameter sets defined in this note is roughly 128
bits, even assuming that there are quantum computers that can compute
the input to an arbitrary function with computational cost equivalent
to the square root of the size of the domain of that function <xref
target="Grover96"/>.  
</t>
<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 distinct from
all others, with very high probability.  This property is important for a
proof of security in the random oracle model.  The formats used during
key generation and signing are
</t>
<figure>
<artwork>
   S || tmp || u16str(i) || u8str(j) || D_ITER
   S || y[0] || ... || y[p-1] || D_PBLC          
   S || C || message || D_MESG 
   I || OTS_PUB[r-2^h]  || u32str(r) || D_LEAF    
   I || T[2*r] || T[2*r+1] || u32str(r) || D_INTR 
   I || u32str(q) || x_q[j-1] || u16str(j) || D_PRG
</artwork>
</figure>
<t>
Because the suffixes D_ITER, D_PBLC, D_LEAF, D_INTR, and D_PRG are
distinct, the input formats ending with different suffixes are all
distinct.  It remains to show the distinctness of the inputs for each
suffix.
</t>
<t>
The values of I and C are chosen uniformly at random from the set of
all n*8 bit strings.  For n=32, it is highly likely that each value of
I and C will be distinct, even when 2^96 such values are chosen.
</t>
<t>
For D_ITER, D_PBLC, and D_MESG, the value of S = I || u32str(q) is
distinct for each LMS leaf (or equivalently, for each q value).  For
D_ITER, 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 S, 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 D_PRG, for a
given value of I, q and j are distinct for each invocation of H (note
that x_q[0] = SEED when j=0).
</t>

<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 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 over), 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, because the hash operation dominates any measure of
performance, and XMSS performs four compression function invocations
(two for the PRF, two for the F function) where HSS need only perform
one.  Additionally, HSS is somewhat simpler, and it admits a single-level
tree in a simple way (as described in <xref target="siggen"/>).
</t>
<t>
Another advantage of HSS is the fact that it can use a stateless
hash-based signature scheme in its non-volatile levels, while
continuing to use LMS in its volatile levels, and thus realize a
hybrid stateless/stateful scheme as described in <xref
target="STMGMT"/>.  While we conjecture that hybrid schemes will offer
lower computation times and signature sizes than purely stateless
schemes, the details are outside the scope of this note.  HSS is
therefore amenable to future extensions that will enable it to be used
in environments in which a purely stateful scheme would be too
brittle.
</t>
<t>
SPHINCS <xref target="SPHINCS"/> is a purely stateless hash based
signature scheme.  While that property benefits security, its
signature sizes and generation times are an order of magnitude (or
more) larger than those of HSS, making it more difficult to adopt in
some practical scenarios.
</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 and Philip Lafrance 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.  
</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="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 Hulsing" initials=".">       </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, 
  </t>
  <t>
   D_PRG is a diversification constant, 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) || SEED || u16str(j) || D_PRG).
</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.
</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>
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>
<figure>
<preamble>The parameters u, v, 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 = (number of bits in sum) - (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. The "number
of bits in sum" is defined according to <xref target='ldwm_msg_chksum'/>. 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.
</postamble>
</figure>
<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>16</c> <c>1</c> <c>128</c> <c>8</c>  <c>8</c> <c>137</c>
<c>16</c> <c>2</c> <c>64</c>  <c>4</c>  <c>8</c> <c>68</c>
<c>16</c> <c>4</c> <c>32</c>  <c>3</c>  <c>4</c> <c>35</c>
<c>16</c> <c>8</c> <c>16</c>  <c>2</c>  <c>0</c> <c>18</c>
<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; num_lmots_keys; i = i + 1 ) {
    r = i + num_lmots_keys;
    temp = H(I || OTS_PUBKEY[i] || u32str(r) || D_LEAF)
    j = i;
    while (j % 2 == 1) {
      r = (r - 1)/2; j = (j-1) / 2;
      left_size = pop(data stack);
      temp = H(I || left_side || temp || u32str(r) || D_INTR)
    }
    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 title="Example Implementation" anchor="example">
<t>
An example implementation can be found online at
http://github.com/davidmcgrew/hash-sigs/.
</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 public key
LMS type    00000005                         # LMS_SHA256_M32_H5
LMOTS_type  00000004                         # LMOTS_SHA256_N32_W8
I           a5f1da931d9acad25800936e78400a9f
            35e42c3026a95f52c3380dcec2cedc86
            67c3d6060c407aea9101c37298e38c31
            b54d8bb61a2c9668d01216814cc3788c
K           348ed79a731eabe47a3cd7ab603ef8de
            6db2e83eaa08fe742cdeb36e635590e2
--------------------------------------------
--------------------------------------------
</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           00000001
--------------------------------------------
LMOTS signature
LMOTS type  00000004                         # LMOTS_SHA256_N32_W8
C           c638b5aa5d3ebec1648986cff65a1b2e
            7213487c25c6fe15b1c859603f741e16
y[0]        b11e8ec40acfc44e74248c312cc8b027
            7fb992afb099f43cd69675b7bd6c22aa
y[1]        84ddb5ceade53f2097dae9b124be8773
            b275d470efa1038437378d8756092b17
y[2]        1bd8bac797db1a3e977f28e73aff1c3b
            94bd3dacca4af4384b6271742e25c841
y[3]        9a9d179629c2b966c0eb25a998243094
            d5f1a7185c0fdf0d9bf9dfa707cbae82
y[4]        545c4e5e2d86db1fad025f41e13276d0
            d28559d5ab81bd81fc97b63f914e1606
y[5]        ddd89cd611fe2a766f4e98d5932c1a27
            1d879592794f84e7decfcef6e9f00d0d
y[6]        2e20b82d50149fc5a5fe2a4c42e1dd10
            85e9a151c9bc11417b388a2b7018ec1a
y[7]        731c1077e54f8b8eba828d3a3462ed6c
            f340c7e8a93364df9174127a57463ea1
y[8]        ad3c122d9eb92e29dd97b1a0f9165a09
            c1f1f5eb4d0315d287fdcbff30a4fe15
y[9]        59eb238bb17c0583df83c5aac1cf5a85
            d72c12e2522090b5a130c4e580687b97
y[10]       62d897571b95c3c61d7dac8168a60a1e
            c1c38879129d30c99ecccf51edd0699e
y[11]       170b88ba98253729134e00e81e523f82
            ef5eaba611a10c3955eb0548918cd103
y[12]       fc40ee27c672af4fbc42f314cb1fc0c1
            5d42a6372bbe83b22f9334629b4af452
y[13]       00b60c768eb1cb888220ee2c4f08ba59
            bbb4b7793a5651e3dd10ef4b0bb5ed24
y[14]       9740e05d35f8670ff6271c5503a6be87
            7561f9e6f4c81e1b903e5048b20b5fb2
y[15]       dad7f51142c23faa4ecd2774b2e25fee
            73a93f02466c3fb9d80b10e4becf7d81
y[16]       1b6a0f4590231de56e0275466790feb0
            26f15e65c26dc45beb908afdba13e560
y[17]       46cac18acb86b10f96a5fcb59b07999c
            04f6febe461220c544dcc8328767c5a0
y[18]       01e434d65bc787ffd952f1404496f3f1
            dd91260e929c60c2725bde980438e591
y[19]       c0eb0788c2d40a867028f1109b80f6a3
            32c4c54ef39078df71a89dda43053c36
y[20]       c13d2ffb54c5b236d32eb07ea08ea3eb
            147fca0367512330736781d028756e53
y[21]       2b4e109b812789d44079e8f3c7833362
            4c0b5255b14057404168710a802cedd1
y[22]       b39be11a52cfbb522b17e796004ae6a7
            0c17aee15eb0d8f8239c5c95d3143633
y[23]       92d30c6c2268f27eeb0f64ff46312e47
            8ca388c37d895d1850f8abb5ac4f4d62
y[24]       39eac305ec8fd13a4a1f537b46e71d26
            3ee4ff2066256b8f1facf42d90e439a2
y[25]       2511733d1c27a3a76fd6d34b8c2d6c98
            419756af39148825a60c0bab0dc5e44d
y[26]       eb282478ecde2460b045e0b4f1649b23
            24eb21570d2804ebb331fef94b6a09d4
y[27]       f6139d54e2ec15b5c770ae0dda018748
            82f0a04e8d61d7f7985668fad9295aa8
y[28]       b851fa7a223c9bd8b7badb46ba7a6474
            e269f0261693af2589f2ba948616946d
y[29]       7d9e09f8c2d2311884469b0910990cc1
            952eba6dcf6ffbd7fe348c79698b9e74
y[30]       01f370a89c4de025393ccdd6ea4278e3
            07dd69025a77ad13f91d55dd8b11d320
y[31]       9b10acf760ca29f58866836dfbc00e1c
            790d63bac8cdea86408df23a7c780259
y[32]       db23d2482b65f2f4f5613660ef7a27e1
            a4cc4cd695fe7cd52be2c5f1a7140a38
y[33]       59f431952579592822aa15389fffb05d
            3528f92b91a8f376a5af2cb61fd8d2c5
--------------------------------------------
LMS type    00000005                         # LMS_SHA256_M32_H5
path[0]     76b85fb075704d6cd66c6d9c48c512ad
            5a41e84ef199ff2d07300400357a032d
path[1]     ef12462838a0fe139bb8b429eeb4e76e
            09b704611bdbb30c107db13076e52ee6
path[2]     055b20ae2af30d52b9e0d1194b979b5f
            897f23437a33c0f3099a4fe0f79662b8
path[3]     1fbd4cbf61a92e5eb45fa68358410cb7
            812540c560ed7bd2256cc912a80f5260
path[4]     6b60e09d773b729d806ace549227b376
            2fa7a55942b07a77b165e0d729899617
pub[0]: 
--------------------------------------------
LMS public key
LMS type    00000005                         # LMS_SHA256_M32_H5
LMOTS_type  00000004                         # LMOTS_SHA256_N32_W8
I           9fc3084bbea5e6d31af8586bc14d8154
            f5532b14745e196dcadd820aa11ea137
            f06a326778eeb875c6035934ee6470ae
            8bfa18f1a1d36e1553f28aa87b878006
K           2d7920997295fc74ad49ea4c5ad6735e
            1e967c966766924b799e734ae922989a
--------------------------------------------
final_signature: 
--------------------------------------------
LMS signature
q           00000009
--------------------------------------------
LMOTS signature
LMOTS type  00000004                         # LMOTS_SHA256_N32_W8
C           8c721faaa063d1c0a5acef3cc83b4f3a
            a3c3863586030c2fb1abdbbff08baf34
y[0]        36a7fc7f0287f1fc10ca471502bae902
            bed6be97b576ef330e119bc93f043811
y[1]        d5de1e0a4431f850d1d264bf880628aa
            9f53c66a23b3f87075651dfc4a05de3e
y[2]        bc8a1addc634dc1f38f27dbfee708169
            78007e9400618586b715c15ca153a1fa
y[3]        1d3a4711354893db705500d8d2b4ae98
            3fc358de7817ba6da1baaee64e670f43
y[4]        7fe3675543c548d8e3b23430b86dfb16
            27164c4b953086bc544ebcbef54c9437
y[5]        f79837dcc32e158f7858c5ad3c09628c
            b1715ae69c3489cf617527956385f7c9
y[6]        bf1a7365629691b10499e39405b07edc
            3464fd71170af8e50e06f644778b337e
y[7]        42b3a15affcd482de83dc1d408cfdf4a
            2b0e4566a09eaaae8269a0695c00b1a7
y[8]        3e482cf25b44d65474276cfc34f7991d
            15cb1defb2236fa7b697362cd9e6d1e0
y[9]        5dd1342b137d7d3a54374dba7ba5741e
            1aaa2831ff62dfdf52b8aee2559fb27c
y[10]       aebe546a5006b857692c32f0f6a8386d
            96646631e953942126d7793715245caa
y[11]       1704d819e50f2a2ec6c1271ed47db819
            b8ea3529a343818ec58c14206bbb5eea
y[12]       681897efa723779ffd970ee4d8841bee
            c87cf9cc14a5369d3196a3331e057be4
y[13]       e7b4c26fa6e74c916cd73be77406812d
            7dd1258e14dcf4ebb2b137d5f9a1d628
y[14]       e4d661b240c0c6f75e954e1872c2d135
            cb0b758c270b42193ab9838c360c8dc5
y[15]       43b7dfd7e6d49778f3eeb328ddb57078
            f24610b710ba20a01fccdec1f3f02763
y[16]       776ddbd8c82e25f6ab0f46cd1f776ffc
            00c1c55ef5f2429ad12501a8ad876901
y[17]       1d51dee1851abc129fa99aae096d1da1
            8acb95f7f78b5adeaaa4d4ea53984b1a
y[18]       a562394d39c479b93fea1db213e3685a
            8a9368b16fd4b3086729f61ec3d65ff8
y[19]       f4f634d430522606761ee1ad522f5a86
            573c5e7b0f6aeb90d1bdfb0cdec61272
y[20]       52b4b07683a59441377899e9558f5181
            56318c83fb6a9c1c0a49b43d3ae08dec
y[21]       221d0f3bc0230d9c080e06bddfce2f12
            3b0bc012644aed82f4d565564461d814
y[22]       62c401a74d41959720dd05dc717d3bcd
            2790ddd2af0e4d6214990b0fee5fdaed
y[23]       8af103391e6edceb8d08554249092ebe
            949f8b1671ceabb7f6a991163da95372
y[24]       0b384b59c8589030165bb90917b9a9a7
            9462eecf5f6196280d23129011ddbd5e
y[25]       4c99f50a7ae2cf8debc7d0034c39eb3f
            33b67889073c62b7fbcccadc4921763c
y[26]       512a485d8cc78f80a783a84348e17411
            7a4e3716319316a2eb42c014a54616e8
y[27]       40156b0d511f8762c3d2a0a3946e0b6f
            993320206c930980cd6a9751e57c62dc
y[28]       aa1cf6303ca775d71a91629bd904ac20
            35226dc9d5b653dcd30673738374829f
y[29]       f57d72293c0f1b3666004667248881bd
            9338b59b049f4e0091f5d39879fca9b6
y[30]       6c0d4b4eb19d9e63fef18f5657974ff4
            d36bf23055dcb6ed4f7e5ce1ad04bfac
y[31]       e91630344345eea1470efb49e4854411
            8a09561d498e90a50c8d68c3e726d15b
y[32]       f20871eaa508b929a5210bc027c92038
            07a94c1cae545a97baf6dd961eddb72f
y[33]       5fd33572aae2da10093c3600e26ead7e
            eaa9e1dce4f253985f4f922b77057535
--------------------------------------------
LMS type    00000005                         # LMS_SHA256_M32_H5
path[0]     e89d230cd37998a27929b8ac966a76c6
            73ae712267ab51ee82c754dc583efb34
path[1]     a6f3e4f96984891c7bbc80468a88aedd
            e5e6661e32d84c106f5353d660092428
path[2]     affef3d925d9f0da2b7a5bbafc5099e2
            169b29695c69a425bab93ece3fcfa376
path[3]     75c32f006ef4599340508179caa9da3c
            574b16721535ce74b1e287e507aab414
path[4]     0ea5e46102296e0bb564d99520b5593f
            25c07a581408d453ce99d615f565ebc2
</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>
