<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!--
<!ENTITY rfc4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
-->
<!ENTITY rfc4309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY rfc4366 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml">
<!ENTITY rfc5288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5288.xml">
<!ENTITY ietf-tls-rfc4346-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4346-bis.xml">
<!ENTITY ietf-tls-rfc4347-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4347-bis.xml">
<!ENTITY ietf-tls-ctr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-ctr.xml">
<!ENTITY rescorla-tls-suiteb SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rescorla-tls-suiteb.xml"> 
<!ENTITY I-D.draft-mcgrew-fundamental-ecc PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcgrew-fundamental-ecc-04.xml">
<!--
<!ENTITY I-D.draft-ietf-tls-rfc4347-bis   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tls-rfc4347-bis-03.xml">
-->

<!ENTITY rfc2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY rfc4309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY rfc4506 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4506.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5116 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5116.xml">
<!ENTITY rfc5430 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5430.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc4492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY rfc6090 SYSTEM "http://xml.resource.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-01">

  <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>

    <date month="February" year="2013"/>
    <!-- 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.  It specifies a one-time
      signature scheme based on the work of Lamport,
      Diffie, Winternitz, and Merkle (LDWM), and specifies
      a general signature system using a Merkle tree.  These
      systems provide asymmetric authentication without
      using large integer mathematics and achieve a high 
      security level.
      They are suitable for compact
      implementations, are relatively simple to implement,
      and naturally resist side-channel attacks.  Unlike
      most other signature systems, hash-based signatures
      would still be secure even if it proves feasible for
      an attacker to build a quantum computer.
      </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, and have benefited from renewed
development in the last decade.  The characteristics of these
signature systems are small private and public keys and low
computational cost, but large signatures.  In recent years there has
been interest in these systems because of their post-quantum security
(see <xref target="pq"/>) and their suitability for compact
implementations.
</t>
<t>
This note describes the original Lamport-Diffie-Winternitz-Merkle
(LDWM) one-time signature system (following Merkle 1979 but also using
a technique from Merkle's later work <xref target="C:Merkle87"/><xref
target="C:Merkle89a"/><xref target="C:Merkle89b"/>) and Merkle tree
signature system (following Merkle 1979) with enough specificity to
ensure interoperability between implementations.  While the
specification of the algorithms follows these early references, the
security considerations makes use of more recent security analyses
(especially Buchmann, Dahmen, Ereth, Hulsing, and Ruckert 2011).
</t>
<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 exactly one message
securely.  A general signature system can be used to sign multiple
messages.  The Merkle Tree Signatures (MTS) is a general signature
system that uses an OTS system as a component.  In principle the MTS
can be used with any OTS system, but in this note we describe its use
with the LDWM system.
</t>
<t>
This note is structured as follows.  Notation is introduced in 
<xref target="notation"/>.  The LDWM signature system is described in
<xref target="ldwm"/>, and the Merkle tree signature system is
described in <xref target="merkle"/>.  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="Notation" anchor="notation">
<section title="Data Types" anchor="datatypes">
<t>
Bytes and byte strings are the fundamental data type.  A single byte
is denoted as a pair of hexadecimal digits with a leading "0x".  A
byte string is an ordered sequence of zero or more bytes and is
denoted as an ordered sequence of hexadecimal characters with a
leading "0x".  For example, 0xe534f0 is a byte string with a length of
three.  An array of byte strings is an ordered set, indexed starting at zero,
in which all strings have the same length.  
</t>
<t>
A byte can be considered as a sequence of eight bits, a sequence of four duets
(two bit unsigned integers), or a sequence of two quartets (four bit
unsigned integers).  A bit has value 0 or 1.  A duet has a value between
0 and 3, and a quartet has value between 0 and 15 decimal (F
hexadecimal).
</t>
<figure>
<preamble>The correspondence between bytes, bits, duets, and
quartets is shown below, where X denotes the value of the byte:</preamble>
<artwork>
                    Byte (8-bit element)
                 +-----------+-----------+ 
                 |           X           | 
                 +-----------+-----------+ 
           
                   Bits (1-bit elements)              
                 +--+--+--+--+--+--+--+--+    
                 |b0|b1|b2|b3|b4|b5|b6|b7|    
                 +--+--+--+--+--+--+--+--+    
           
                  Duets (2-bit elements)    
                 +-----+-----+-----+-----+ 
                 |  d0 |  d1 |  d2 |  d3 | 
                 +-----+-----+-----+-----+ 
           
                 Quartets (4-bit elements)
                 +-----------+-----------+ 
                 |     q0    |     q1    | 
                 +-----------+-----------+ 
         
   X = 128*b0 + 64*b1 + 32*b2 + 16*b3 + 8*b4 + 4*b5 + 2*b6 + b7
   X = 64*d0 + 16*d1 + 4*d2 + d3
   X = 16*q0 + q1
</artwork>
</figure>
<figure>
<preamble>For example, the following diagram
shows how the byte with decimal value 27 (hexadecimal value 0x1b)
is represented with bits, duets, and quartets.</preamble>
<artwork>   
                    Byte (8-bit element)
                 +-----------+-----------+ 
                 |          27           | 
                 +-----------+-----------+ 
           
                  Bits (1-bit elements)              
                 +--+--+--+--+--+--+--+--+    
                 | 0| 0| 0| 1| 1| 0| 1| 1|
                 +--+--+--+--+--+--+--+--+    
           
                  Duets (2-bit elements)    
                 +-----+-----+-----+-----+ 
                 |  0  |  1  |  2  |  3  | 
                 +-----+-----+-----+-----+ 
           
                 Quartets (4-bit elements)
                 +-----------+-----------+ 
                 |     1     |     b     | 
                 +-----------+-----------+ 
</artwork>
</figure>
<!--
<t>
The set of w-bit unsigned integers is denoted as { 0, 1, ... , 2^w-1 }.
</t>
-->
<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.  For example, if S = 0x0204ff, then byte(S, 0) is 0x02.
</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>   
                   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 Quartets)
      +-----------+-----------+-----------+-----------+
      |     1     |     2     |     3     |     4     |
      +-----------+-----------+-----------+-----------+
            ^
            |
      coef(S, 0, 4)
</artwork>
</figure>
<t>
The return value of coef is an unsigned integer.  
If i is larger than the number of w-bit values in S, then
coef(S, i, w) is undefined, and an attempt to compute
that value should raise an error.
</t>
</section>

</section>
<section title="Operators" anchor="operators">
<t>
When a and b are 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 a divided 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>
If A and B are bytes, then A AND B denotes the bitwise logical and
operation.
</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.
</t>
<!--
<t>
The set of all strings of n bytes is denoted as B^n.  The set of
strings of all lengths (from zero upwards) is denoted as B^*.
The set of all possible length p arrays of n-byte strings
is denoted as (B^n)^p.
</t>
-->
<t>
The i^th byte string in an array A is denoted as A[i].
</t>
</section>
<section title="Functions" anchor="functions">
<t>
If r is a non-negative real number, then we define the following functions:
<list>
<t>ceil(r) : returns the smallest integer larger than r</t>
<t>floor(r) : returns the largest integer smaller than r</t>
<t>lg(r) : returns the base-2 logarithm of r</t>
</list>
</t>
<t>
When F is a function that takes m-byte strings (i.e. byte strings of length m) as input and returns m-byte strings as output,
we denote the repeated applications of F with itself a non-negative, integral number of times i as F^i.
</t>
<figure>
<preamble>Thus for any byte string x,</preamble>
<artwork>
    F^i(x) = / F( F^(i-1)(x) )  for i > 0
             \ x                for i = 0.
</artwork>
<postamble>For example, F^2(x) = F(F(x)).</postamble>
</figure>
<!--
<t>
The direct product of two sets S1 and S2 is denoted as S1 x S2.
</t>
-->
<!--
<t>
We describe the inputs and outputs of a function F using
the mathematical notation, as 
<artwork>
   F : InputSet -> OutputSet,
</artwork>
where InputSet is the set of all possible inputs, and OutputSet
is the set of all possible outputs.  For instance, if the function
F took as input a w-bit integer and an arbitrary length byte
string, and returned a single bit value, that fact is denoted as
<artwork>
   F : { 0, 1, ... , 2^w-1 } x B^* -> { 0, 1 }.
</artwork>
</t>
-->
</section>
</section>

<!--
<section title="Interface" anchor="interface">
<t>
The LDWM and Merkle signature system have the following functions:
<list>
  <t>
    GeneratePrivateKey : B^m -> PrivateKey
  </t>
  <t>
    GeneratePublicKey : PrivateKey -> PublicKey   
  </t>
  <t>
    GenerateSignature : PrivateKey x B^* -> Signature
  </t>
  <t>
    VerifySignature : PublicKey x B^* -> { 0, 1 }
  </t>
</list>
The sets PrivateKey, PublicKey, and Signature are different
for each signature system, as described below.
</t>
</section>
-->

<section anchor="ldwm" title="LDWM One-Time Signatures">
<t>
This section defines LDWM signatures.  The signature is used to validate
the authenticity of a message by associating a secret private key with
a shared public key.  These are one-time signatures; each 
private key MUST be used only one time to sign any given message.  
</t>
<t>
Note that in order to constrain what constitutes the "message" and establish
fixed sizes for the signature, a digest of the original message is 
computed using a collision-resistant hash function, H (see
<xref target='ldwm_hash_func' />).
</t>
<section title='Parameters' anchor='ldwm_params'>
<t>
The signature system uses the parameters m, n, and w; they are all positive
integers.  The algorithm description also uses the value p.  These parameters
are summarized as follows:
<list>
<t>m : the length in bytes of each element of an LDWM signature</t>
<t>n : the length in bytes of result of the hash function</t>
<t>w : the Winternitz parameter; it is a member of the set {&nbsp;1,&nbsp;2,&nbsp;4,&nbsp;8&nbsp;}</t>
<t>p : the number of m-byte string elements that make up the LDWM signature;
it is equivalent to the number of w-bit elements of (&nbsp;H(message)&nbsp;||&nbsp;C(H(message))&nbsp;)
as well as the number of n-byte strings that form the private key; it can be specified in terms of
u and v, as shown in <xref target='ldwm_param_opts' />.</t>
<t>ls : the number of bits the checksum function C will left-shift the sum total of
hashing operations required by the verifier before returning a result</t>
</list>
</t>
<t>
The values of m and n are determined by the functions selected for use as part of
the LDWM algorithm.  They are chosen to ensure an appropriate level of
security.  The parameter w can be chosen to set the number of bytes in the signature;
it has little effect on security.  Note however, that there is a
larger computational cost to generate and verify a shorter signature.
The values of p and ls are a direct result of the choices of n and w.  

<xref target='ldwm_param_opts' /> describes how p and ls depend on the other parameters.
A table illustrating various combinations of n, w, p, and ls is provided in <xref target='tbl_ldwm_params' />.
</t>
</section>
<section title='Hashing Functions' anchor='ldwm_hash_func'>
<t>
The LDWM algorithm requires a robust one-way function to underpin the signature
generation and verification.  Let this be defined as a hash function H that has
inputs of any integral byte length and has n-byte outputs.
</t>
<t>
In addition, let F be defined as a one-way function that has m-byte inputs and
m-byte outputs.
</t>
</section>
<section title='Signature Methods' anchor='ldwm_methods'>
<t>
To fully describe a LDWM signature method, the parameters m, n, and w,
as well as the functions H and F MUST be specified.  This section defines
several LDWM signature systems, each of which is identified by a name.
Values for p and ls are provided as a convenience.
</t>
<texttable anchor='ldwm_sig_table'>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>H</ttcol>
<ttcol align='left'>F</ttcol>
<ttcol align='left'>m</ttcol>
<ttcol align='left'>n</ttcol>
<ttcol align='left'>w</ttcol>
<ttcol align='left'>p</ttcol>
<ttcol align='left'>ls</ttcol>
<c>LDWM_SHA256_M20_W1</c> <c>SHA256</c> <c>SHA256-20</c> <c>20</c> <c>32</c> <c>1</c> <c>265</c> <c>7</c>
<c>LDWM_SHA256_M20_W2</c> <c>SHA256</c> <c>SHA256-20</c> <c>20</c> <c>32</c> <c>2</c> <c>133</c> <c>6</c>
<c>LDWM_SHA256_M20_W4</c> <c>SHA256</c> <c>SHA256-20</c> <c>20</c> <c>32</c> <c>4</c> <c>67</c> <c>4</c>
<c>LDWM_SHA256_M20_W8</c> <c>SHA256</c> <c>SHA256-20</c> <c>20</c> <c>32</c> <c>8</c> <c>34</c> <c>0</c>
</texttable>
<t>
Here SHA256 denotes the NIST standard hash function.  
SHA256-20 denotes that hash function with its final output truncated
to 20 bytes.
</t>
</section>
<section title='Private Key' anchor='ldwm_prv_key'>
<t>
The LDWM private key must be an array of size p containing n-byte strings.
Let x denote the private key. This private key must be used to sign one and
only one message. It must therefore be unique from all other private keys.
The following algorithm shows pseudocode for generating x.
</t>
<figure>
<preamble>Algorithm 0: Generating A Private Key</preamble>
<artwork>
  for i=0,i&lt;p,i++
    set x[i] to a uniformly random value
  endfor
  return x
</artwork>
<postamble>Note that one possible implementation may consist of a single random
input to a suitable key derivation function.</postamble>
</figure>
</section>
<section title='Public Key' anchor='ldwm_pub_key'>
<t>
The LDWM public key is generated from the private key through a series of
hashing operations using the functions F and H. Its value is the hash
(using H) of the concatenation of the elements of an array y. The content
of y is generated by iteratively hashing (using F) each element of
array x, (2^w - 1) times. The following algorithm shows pseudocode for
generating the public key.
</t>
<figure>
<preamble>Algorithm 1: Generating a Public Key From a Private Key</preamble>
<artwork>
  e = 2^w - 1
  for i=0,i&lt;p,i++ 
    y[i] = F^e(x[i])
  endfor
  return H(y[0] || y[1] || ... || y[p-1])
</artwork>
</figure>
</section>
<section title='Checksum' anchor='ldwm_msg_chksum'>
<t>
A checksum is used to prevent the manipulation of an existing signature
in an attempt to produce a new signature for a different message outside of the
normal signing process. The security property is detailed in <xref target='Security' />.
</t>
<t>
The checksum value is calculated using a non-negative integer, sum, whose width is sized
an integer number of w-bit fields such that it is capable of holding the difference of the
total possible number of applications of the function F as defined in the signing
algorithm of <xref target='ldwm_sig_gen' /> and the total actual number. In the
worst case (i.e. the actual number of times F is iteratively applied is 0), the sum is
(2^w - 1) * ceil(8*n/w).
Thus for the purposes of this document, which describes signature methods based on H =
SHA256 (n = 32 bytes) and w = { 1, 2, 4, 8 }, let sum be a 16-bit non-negative integer for
all combinations of n and w. The checksum function C is defined as follows where S is a
byte string provided to the function as an argument.
</t>
<figure>
<preamble>Algorithm 2: Checksum Calculation</preamble>
<artwork>
  sum = 0
  for i=0,i&lt;u,i++
    sum = sum + (2^w - 1) - coef(S, i, w)
  endfor
  return (sum &lt;&lt; ls)
</artwork>
<postamble>Because of the left-shift operation, the rightmost
bits of the result of C 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, the implementation may therefore choose to optimize the
width of sum to (v * w) bits and set ls to 0. The rationale for this is given that
(2^w - 1) * ceil(8*n/w) is the maximum value of sum and the value of (2^w - 1) is
represented by w bits, the result of repeatedly adding two w-bit numbers a total of
u = ceil(8*n/w) times requires at most (floor(lg(u)) + w) bits.
Dividing by w and taking the next largest integer gives the total required number of
w-bit fields and gives (ceil(floor(lg(u)) / w) + 1), or v. Thus sum requires a
minimum width of (v * w) bits and no left-shift operation is performed.
</t>
</list>
</t>
</section>
<section title='Signature Generation' anchor='ldwm_sig_gen'>
<t>
The LDWM signature is generated by using the values of the w-bit fields that compose
the hash of the message and its checksum to determine the number of times to apply
the function F to the elements of the private key. This signature is provided by the
signer to the verifier along with the message and the public key.
</t>
<figure>
<preamble>Algorithm 3: Generating a Signature From a Private Key and a Message</preamble>
<artwork>
  V = ( H(message) || C(H(message)) )
  for i=0,i&lt;p,i++
    a = coef(V, i, w)
    y[i] = F^a(x[i])
  endfor
  return ( y[0] || y[1] || ... || 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>
</section>
<section title='Signature Verification' anchor='ldwm_sig_vrf'>
<t>
In order to verify a message with its signature (denoted as y',
an array of m-byte strings), the receiver must "complete" the series
of applications of F using the value of the message hash and its checksum. This should
result in a computation of the public key that matches the public key provided.
</t>
<figure>
<preamble>Algorithm 4: Verifying a Signature and Message Using a Public Key</preamble>
<artwork>
  V = ( H(message) || C(H(message)) )
  for i=0,i&lt;p,i++
    a = (2^w - 1) - coef(V, i, w)
    z[i] = F^a(y'[i])
  endfor
  if public key is equal to H(z[0] || z[1] || ... || z[p-1])
    return 1 (message signature is valid)
  else
    return 0 (message signature is invalid)
</artwork>
</figure>
</section>
<!-- must the private key and public key be equal in length? -->
<!--t> 
An LDWM private key is an n-byte string, and an LDWM public key is
also an n-byte string.  During signature creation and verification, the byte string
( message || checksum ) is divided into a number of w-bit fields, p.  An LDWM
signature thus consists of an array of p elements, each element of which is an m-byte
string.  Therefore, the value of p is determined by the values of n and w.
</t>
<t>
The signature method uses the following functions:
<list>
<t>
A one-way function F that has m-byte inputs and m-byte outputs.
</t>
<t>
A hash function H that has inputs of any integral byte length 
and has n-byte outputs.
</t>
</list>
Internally, the following functions are used:
<list>
<t>
A function Count that has n-byte inputs and outputs that are two bytes in length.
</t>
</list>

</t-->
<!--t>
The function count is defined as follows, where the variable sum is a
16-bit nonnegative integer:
<artwork>
   sum = 0
   for i=0 to (n/w)-1
     sum = sum + (2^w - 1) - coef(S, i, w)
   endfor 
   shift sum left by LS bits
   return sum
</artwork>
The value LS depends on n and w, is given by the "Left Shift" column
in the table above.  Because of the left shft operation, the rightmost
bits of Count will often be zeros.
</t-->
<!--t>
The relationships between the parameters is as given by the table below; 
these relationships are explained in <xref target="rationale"/>.
</t-->
<!--section title="LDWM Private Key Generation">
Algorithm 0: generating a private key:
<artwork>
  for i=0,p-1, 
     set x[i] to a uniformly random value
  endfor
  return x
</artwork>
</section>
<section title="LDWM Public Key Generation">
Algorithm 1: generating a public key from a private key:
<artwork>
  e = 2^w - 1
  for i=0,p-1, 
     y[i] = F^e(x[i])
  endfor
  return hash(y[0] || y[1] || ... || y[p-1])
</artwork>
</section-->
<!--section title="LDWM Signature Generation">
Algorithm 2: generating a signature from a private key and a message:
<artwork>
  V = hash(message) || Count(hash(message))
  for i=0,p-1:
      a = coef(V, i, w) 
      s[i] = F^a(x[i])
   endfor 
   return s[0] || s[1] || ... || s[p-1]
</artwork>
<t>
</t>
</section-->
<!--section title="LDWM Signature Verification">
Algorithm 3: verifying a signature and message using a public key:
<artwork>
  V = hash(message) || count(hash(message))
  for i=0,p-1:
      a = (2^w - 1) - coef(V, i, w) 
      z[i] = F^a(x[i])
   endfor 
   if public key is equal to hash(z[0] || z[1] || ... || z[p-1])
      return 1 (signature is valid)
   else
      return 0 (signature is invalid)
</artwork>  
</section-->
<section title="Notes" anchor="ldwm_notes">
<t>
A future version of this specification may 
define a method for computing the signature
of a very short message in which the hash
is not applied to the message during
the signature computation.  That
would allow the signatures to have reduced size.
</t>
</section>
<!--section title="Parameters">
<t>
To fully describe a LDWM signature method, the parameters m, n, and w,
as well as the functions hash() and F() MUST be specified.  This section defines
several LDWM signature systems, each of which is identified by a name.
</t>
<texttable anchor='ldwm_sig_table'>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Hash</ttcol>
<ttcol align='left'>F</ttcol>
<ttcol align='left'>m</ttcol>
<ttcol align='left'>n</ttcol>
<ttcol align='left'>w</ttcol>
<ttcol align='left'>p</ttcol>
<c>LDWM_SHA256_M20_W1</c> <c>SHA-256</c> <c>SHA-256-20</c> <c>20</c> <c>32</c> <c>1</c> <c>265</c>
<c>LDWM_SHA256_M20_W2</c> <c>SHA-256</c> <c>SHA-256-20</c> <c>20</c> <c>32</c> <c>2</c> <c>133</c>
<c>LDWM_SHA256_M20_W4</c> <c>SHA-256</c> <c>SHA-256-20</c> <c>20</c> <c>32</c> <c>4</c> <c>67</c>
<c>LDWM_SHA256_M20_W8</c> <c>SHA-256</c> <c>SHA-256-20</c> <c>20</c> <c>32</c> <c>8</c> <c>34</c>
</texttable>
<artwork>
Name                Hash      F             m   n   w    p  ls
----------------------------------------------------------------
LDWM_SHA256_M20_W1  SHA-256   SHA-256-20   20  32   1  265   8
LDWM_SHA256_M20_W2  SHA-256   SHA-256-20   20  32   2  133   8
LDWM_SHA256_M20_W4  SHA-256   SHA-256-20   20  32   4   67   4
LDWM_SHA256_M20_W8  SHA-256   SHA-256-20   20  32   8   34   0
</artwork>
<t>
Here SHA-256 denotes the NIST standard hash function.  
SHA-256-20 denotes that hash function with its output truncated
to 20 bytes.
</t>
</section-->
<section title="Formats" anchor="ldwm_xdr">
<figure>
<preamble>The signature format is defined using XDR <xref target="RFC4506" /> as follows:</preamble>
<artwork>
<![CDATA[/*
 * ldwm_algorithm_type identifies a particular signature algorithm
 */
enum ldwm_algorithm_type {
  ldwm_reserved = 0,
  ldwm_sha256_m20_w1  = 1,
  ldwm_sha256_m20_w2  = 2,
  ldwm_sha256_m20_w4  = 3,
  ldwm_sha256_m20_w8  = 4
};

/*
 * basic data types; b16 is a string of 16 bytes, and so on
 */
typedef opaque b16[16];
typedef opaque b20[20];
typedef opaque b24[24];
typedef opaque b28[28];
typedef opaque b32[32];

/*
 * arrays 
 */
typedef b20 b20_array_265[265];
typedef b20 b20_array_133[133];
typedef b20 b20_array_67[67];
typedef b20 b20_array_34[34];

union ldwm_signature switch (ldwm_algorithm_type type) {
 case ldwm_sha256_m20_w1:
   b20_array_265 y265;
 case ldwm_sha256_m20_w2:
   b20_array_133 y133;
 case ldwm_sha256_m20_w4:
   b20_array_67 y67;
 case ldwm_sha256_m20_w8:
   b20_array_34 y34;
 default:
   void;   /* error condition */
};]]>
</artwork>
</figure>
<t>
Though the data formats are formally defined by XDR, we describe the
format as well as a convenience to the reader.  An example of the
format of an ldwm_signature is illustrated below, for
ldwm_sha256_m20_w1, which has 265 elements, each of which is a
20-octet string.  An ldwm_signature always consists of a 32-bit
unsigned integer that indicates the ldwm_algorithm_type followed by an
array of equal-length octet strings.  The number of octets in each
octet string, and the number of elements in the array, are determined
by the ldwm_algorithm_type field.  A receiver MUST check the
ldwm_algorithm_type field, and a verification operation on a signature
with an unknown ldwm_algorithm_type MUST return FAIL.
</t>
<figure>
<artwork>
         +---------------------------------+
         |      ldwm_algorithm_type        |
         +---------------------------------+
         |                                 |         
         |           y265[0]               |         
         |                                 |         
         |                                 |         
         +---------------------------------+
         |                                 |         
         |           y265[1]               |         
         |                                 |         
         |                                 |         
         |                                 |         
         +---------------------------------+
         |                                 |         
         ~             ....                ~
         |                                 |         
         +---------------------------------+
         |                                 |         
         |          y265[264]              |         
         |                                 |         
         |                                 |         
         |                                 |         
         +---------------------------------+
</artwork>
</figure>
</section>
<!--
<section title="Example" anchor="ldwm_example">
<t>
CAUTION: this example does not exactly correspond to the
specification provided above.  It can't possibly,
since the specification applies a hash function to the 
message, which would require that the signature
is very large.  This section needs to be rewritten.
</t>
<figure>
<artwork align="center">
  x[0]  ->   F(x[0])  ->   F(F(x[0]))  ->  y[0] = F(F(F((x[0])))) 
  x[1]  ->   F(x[1])  ->   F(F(x[1]))  ->  y[1] = F(F(F((x[1])))) 
  x[2]  ->   F(x[2])  ->   F(F(x[2]))  ->  y[2] = F(F(F((x[2])))) 
  x[3]  ->   F(x[3])  ->   F(F(x[3]))  ->  y[3] = F(F(F((x[3])))) 
  x[4]  ->   F(x[4])  ->   F(F(x[4]))  ->  y[4] = F(F(F((x[4])))) 
  x[5]  ->   F(x[5])  ->   F(F(x[5]))  ->  y[5] = F(F(F((x[5])))) 
</artwork>
</figure>
<figure>
<artwork>
    private key = x[0] || x[1] || x[2] || x[3] || x[4] || x[5] 
    public key = hash(y[0] || y[1] || y[2] || y[3] || y[4] || y[5])
    The signature is F^a[0](x[0]) || F^a[1](x[1]) || ... 
    message being signed  a = a[3] || a[2] || a[1] || a[0]
    m = 2, and a[i] is in { 0, 1, 2, 3 }
</artwork>
</figure>
<t>
  in our example, a is the ASCII character 'S', which is represented
  by the decimal number 83, and
</t>
<figure>
<artwork>
      a = 1 || 1 || 0 || 3
</artwork>
</figure>
<t>
   count(a) is computed as 2 + 2 + 3 + 0 = 7; in base-4, count(a) = c[1] || c[0] = 1 || 3
</t>
<figure>
<artwork>   
      a || C = a[3] || a[2] || a[1] || a[0] || c[1] || c[0] 
             =   1  ||   1  ||   0  ||   3  ||   1  ||  3   
</artwork>
</figure>
<t>
   The signature is { F^1(x[0]), F^1(x[1]), F^0(x[2]), F^3(x[3]), F^1(x[4]), F^3(x[5]) }
</t>
</section>
-->
</section>

<section anchor="merkle" title="Merkle Tree Signatures">
<t>
Merkle Tree Signatures (MTS) are a method for signing a large but
fixed number of messages.  An MTS system uses two cryptographic
components: a one-time signature method and a collision-resistant
hash function.  Each MTS public/private key pair is associated with a
k-way tree, each node of which contains an n-byte value.  Each leaf of
the tree contains the value of the public key of an LDWM public/private
key pair. The value contained by the root of the tree is the MTS public key.
Each interior node is computed by applying the hash function
to the concatenation of the values of its children nodes.
</t>
<t>
  An MTS system has the following parameters:
  <list>
    <t>
      k : the number of children nodes of an interior node,
    </t>
    <t>
      h : the height (number of levels) in the tree, and
    </t>
    <t>
      n : the number of bytes associated with each node.
    </t>
  </list>
There are k^h leaves in the tree.
</t>
<section anchor="mts_priv" title="Private Key">
<t>
  An MTS private key consists of k^h LDWM private keys and the leaf
  number of the next LDWM private key that has not yet been used.  The
  leaf number is initialized to zero when the MTS private key is
  created.
</t>
<t>
  An MTS private key MAY be generated pseudorandomly from a secret
  value, in which case the secret value MUST be n bytes long, be
  uniformly random, and MUST NOT be used for any other purpose than
  the generation of the MTS private key.  The details of how this
  process is done do not affect interoperability; that is, the public
  key verification operation is independent of these details.
</t>
</section>
<section anchor="mts_alg" title="MTS Public Key">
<t>
An MTS public key is defined as follows,
where we denote the public key associated with the
i^th LDWM private key as ldwm_public_key(i).
</t>
<t>
The MTS public key can be computed using the following
algorithm or any equivalent method.   The 
algorithm uses a stack of hashes and a separate stack of integers 
which keeps track of the level of the tree.
</t>
<figure>
<!-- <preamble>The following pseudocode describes the algorithm:</preamble> -->
<artwork>
for i = 0 to num_ldwm_keys by steps of k  
  level = 0
  for j = 0 to k-1
    push ldwm_public_key(i+j) on the data stack
    push level on the integer stack
  endfor
  while the height of the stack is at least k
    if the top k elements on the integer stack are equal
      pop the top k elements of the data stack
      pop the top k elements of the integer stack,
        and set the variable "level" to be their value
      hash the top k elements of the data stack
      push the hash result on the data stack
      push (level+1) on to the integer stack
    endif
  endwhile
endfor
</artwork>
<postamble>Note that the stack never gets bigger than the logarithm of the number of LDWM
public keys, so for typical parameters it will have something like 20 32-byte
elements.</postamble>
</figure>
</section> 
<section anchor="mts_sig" title="MTS Signature">
<t>
An MTS signature consists of 
<list>
  <t> 
    an LDWM signature, 
  </t>
  <t> 
    a node number that identifies the leaf node associated with the signature, and 
  </t>
  <t> 
    an array of values that is associated with the path through the
    tree from the leaf associated with the LDWM signature to the
    root.
  </t>
</list>
The array of values contains contains the siblings of the nodes on the
path from the leaf to the root but does not contain the nodes on the
path itself.  The array for a tree with branching number k and height
h will have (k-1)*h values.  The first (k-1) values are the siblings
of the leaf, the next (k-1) values are the siblings of the parent of
the leaf, and so on.
</t>
<section anchor="mts_sig_gen" title="MTS Signature Generation">
  <t>
    To compute the MTS signature of a message with an MTS private key,
    the signer first computes the LDWM signature of the message
    using the leaf number of the next unused LDWM private key.
    Before releasing the signature, the leaf number in the 
    MTS private key MUST be incremented to prevent the LDWM private key
    from being used again.  
    The node number in the signature is set to the leaf
    number of the MTS private key that was used in the signature.  
  </t>
  <t>
    The array of node values MAY be computed in any way.  There are
    many potential time/storage tradeoffs.  The fastest alternative is
    to store all of the nodes of the tree and set the array in the
    signature by copying them.  The least storage intensive
    alternative is to recompute all of the nodes for each signature.
    Note that the details of this procedure are not important for
    interoperability; it is not necessary to know any of these details
    in order to perform the public key verification algorithm.
  </t>
</section>
</section>
<section anchor="mts_sig_vrf" title="MTS Signature Verification">
<t>
An MTS signature is verified by first using the LDWM signature
verification algorithm to compute the LDWM public key from the LDWM
signature and the message.  The value of the leaf associated with the
LDWM signature is assigned to the public key.
Then the root of the tree is computed from the leaf value
and the node array as described below.  If the root value
matches the public key, then the signature is valid; 
otherwise, the signature fails.  
</t>
<figure>
<preamble>An efficient way to compute the root from the leaf and the node
array is as follows, where n is initially the node number:</preamble>
<artwork>
  v = leaf
  step = 0
  for i=0 to h-1 by steps of 1
    position = n % k 
    hash_init()
    for j=0 to position-1 by steps of 1
      hash_update(node[step + j])
    endfor
    hash_update(v)
    for j=position to (k-1) by steps of 1
      hash_update(node[step + j])
    endfor
    v = hash_final()
    n = floor(n/k)
    step = step + (k-1)
  endfor
</artwork>
</figure>
<t>
  This algorithm uses the typical init/update/final interface to hash functions; 
  the result of the invocations hash_init(), hash_update(N[1]), hash_update(N[2]), 
  ... , hash_update(N[n]), v = hash_final(), in that order, is identical
  to that of the invocation of H(N[1] || N[2] || ... || N[n]).
</t>
<t>
This algorithm works because the leaves of the MTS tree are numbered
starting at zero.  Therefore leaf n is in the position (n % k) in the
highest level of the tree.  
<!-- To figure out the branch number at the
next highest level, set n to floor(n/k) and then the branch number is (n
% k).  To move up another level, set n to floor(n/k) again, and so
on.  
-->
</t>
<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 MTS public key.  
</t>
<t>
A full test example that combines the LDWM OTS and MTS algorithms is given in
<xref target='testing' />.
</t>
</section>
<section anchor="mts_xdr" title="MTS Formats">
<figure>
<preamble>MTS signatures and public keys are defined using XDR syntax as follows:</preamble>
<artwork>
<![CDATA[enum mts_algorithm_type {
  mts_reserved      = 0,
  mts_sha256_k2_h20 = 1,
  mts_sha256_k4_h10 = 2,
  mts_sha256_k8_h7  = 3,
  mts_sha256_k16_h5 = 4
};

union mts_path switch (mts_algorithm_type type) {
 case mts_sha256_k2_h20:
   b32 t20[20]; 
 case mts_sha256_k4_h10:
   b32 t30[30];
 case mts_sha256_k8_h7:
   b32 t49[49];
 case mts_sha256_k16_h5:
   b32 t75[75];
 default:
   void;     /* error condition */
};

struct mts_signature_t {
  ldwm_signature ldwm_sig;
  unsigned int signature_leaf_number;
  mts_path nodes;
};

union mts_public_key switch (mts_algorithm_type type) {
 case mts_sha256_k2_h20:
 case mts_sha256_k4_h10:
 case mts_sha256_k8_h7:
 case mts_sha256_k16_h5:
   b32 z;
 default:
   void;     /* error condition */
};]]>
</artwork>
</figure>
<!--

union mts_private_key switch (mts_algorithm_type type) {
 case mts_sha256_k2_h20:
 case mts_sha256_k4_h10:
 case mts_sha256_k8_h7:
 case mts_sha256_k16_h5:
   b16 x;
 default:
   void;     /* error condition */
};


-->

</section>
</section>

<section anchor="rationale" title="Rationale">
<t>
The goal of this note is to describe the LDWM and MTS algorithms
following the original references and present the modern security
analysis of those algorithms.  Other signature methods are out of
scope and may be interesting follow-on work.  
</t>
<t>
The signature and public key formats are designed so that they are
easy to parse.  Each format starts with a 32-bit enumeration value
that indicates all of the details of the signature algorithm and
hence defines all of the information that is needed in order to parse the
format.
</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-->
</section>

<section title="History">
<t>
This is the initial version of this draft.  
</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 LDWM signatures, as defined in Section 3, and
one for Merkle Tree Signatures, as defined in Section 4.  Additions to
these registries require that a specification be documented in an RFC
or another permanent and readily available reference in sufficient
detail that interoperability between independent implementations is
possible.  Each entry in the registry contains the following elements:
 <list>
   <t>a short name, such as "MTS_SHA256_K16_H5", that starts with the
   strings "MTS" and "LDWM" for the MTS and LDWM registries, respectively,
   </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. These number assignments SHOULD use the smallest available
positive number.  Submitters SHOULD have their requests reviewed
by the IRTF Crypto Forum Research Group (CFRG) at cfrg@ietf.org.
Interested applicants that are unfamiliar with IANA processes
should visit http://www.iana.org.
</t>

<t>
  The numbers between 32,768 (binary 1000000000000000) and
  65,535 (binary 1111111111111111) inclusive, will not be
  assigned by IANA, and are reserved for private use; no attempt
  will be made to prevent multiple sites from using the same
  value in different (and incompatible) ways
  <xref target="RFC2434"/>.
</t>

<t>
The LDWM 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>      LDWM_SHA256_M20_W1 </c>

        <c> <xref target="ldwm"/></c>
	
	<c> 1 </c>

        <c>      LDWM_SHA256_M20_W2 </c>

        <c> <xref target="ldwm"/></c>
	
	<c> 2 </c>

        <c>      LDWM_SHA256_M20_W4 </c>

        <c> <xref target="ldwm"/></c>
	
	<c> 3 </c>

        <c>      LDWM_SHA256_M20_W8 </c>

        <c> <xref target="ldwm"/></c>
	
	<c> 4 </c>



      </texttable>

<t>
The MTS 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>      MTS_SHA256_K2_H20</c>

        <c> <xref target="merkle"/></c>

        <c>1</c>

        <c> MTS_SHA256_K4_H10</c>

        <c>  <xref target="merkle"/></c>

        <c>2</c>

        <c> MTS_SHA256_K8_H7</c>

        <c>  <xref target="merkle"/></c>

        <c>3</c>

        <c> MTS_SHA256_K16_H5</c>

        <c>  <xref target="merkle"/></c>

        <c>4</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="Security" title="Security Considerations">
 <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").
</t>
<t>
LDWM signatures rely on the fact that, given an m-byte string y, it is
prohibitively expensive to compute a value x such that F^i(x) = y
for any i.  Informally, F is said to be a "one-way" function.  
</t>
<section title="Security of LDWM Checksum">
<t>
  To show the security of LDWM 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;C(H(message)) (see <xref target='ldwm_sig_gen' />).  To attempt
  a forgery, an attacker can change the values of h and c.  Let
  h' and c' denote the values used in the forgery attempt.  If for some integer j
  in the range 0 to (u-1), inclusive,
<list style="empty">
  <t>
   a' = coef(h', j, w),
  </t>
  <t>
   a = coef(h, j, w), and 
  </t>
  <t>
   a' > a
  </t>
</list>
  then attacker can compute F^a'(x[j]) from F^a(x[j]) = y[j]
  by iteratively applying function F to the j^th term of the signature
  an additional (a' - a) times.
  However, as a result of this action, the checksum will decrease, and thus a valid
  signature's checksum will have, for some number k in the range u to (p-1), inclusive,
<list style="empty">
  <t>
   b' = coef(c', k, w),
  </t>
  <t>
   b = coef(c, k, w), and
  </t>
  <t>
   b' < 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>
LDWM and MTS signatures have a minimum of security conjectures.  In
particular, their security does not rely on the computational
difficulty of factoring composites with large prime factors (as does
RSA) or the difficulty of computing the discrete logarithm in a finite
field (as does DSA) or an elliptic curve group (as does ECDSA).  All
of these signature schemes rely on the security of the hash function
that they use, but with LDWM and MTS, the security of the hash
function is sufficient.   
</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 LDWM and Merkle signature systems are post-quantum secure if they
are used with an appropriate underlying hash function, in which the
size of m and n are double what they would be otherwise, in order to
protect against quantum square root attacks due to Grover's algorithm.
In contrast, the signature systems in wide use (RSA, DSA, and ECDSA)
are not post-quantum secure.
</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="Acknowledgements" title="Acknowledgements">
<t>
Thanks are due to Chirag Shroff for constructive feedback.  
</t>
</section>

  </middle>
  
  <back>

    <references title="Normative References">

      &rfc2119;

      &rfc2434;
      
      &rfc4506;

<!--
    <reference anchor="AES">
        <front>
          <title>Specification for the Advanced Encryption Standard (AES)</title>
          <author>
            <organization>National Institute of Standards and Technology</organization>
          </author>
          <date month="November" year="2001"></date>
        </front>
        <seriesInfo name="FIPS" value="197"></seriesInfo>
      </reference>
    
-->
  
    </references>

    <references title="Informative References"> 

      <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 title='LDWM 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, w, p, and ls is provided in
<xref target='tbl_ldwm_params' />.
</t>
<figure>
<preamble>The parameters p and ls are computed as follows:</preamble>
<artwork>
  u = ceil(8*n/w)
  v = ceil(floor(lg(u)) / w) + 1
  p = u + v
  ls = (number of bits in sum) - (v * w)
</artwork>
<postamble>
Here u and v represent the number of w-bit fields required to contain the
hash of the message message and the checksum byte strings, respectively.
For a further explanation of the values of v and sum, see <xref target='ldwm_msg_chksum' />.
</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 Checksum</ttcol>
<ttcol align='center'>Left Shift (ls)</ttcol>
<ttcol align='center'>Number of Elements (p)</ttcol>
<c>20</c> <c>1</c> <c>8</c> <c>8</c> <c>168</c>
<c>20</c> <c>2</c> <c>4</c> <c>8</c> <c>84</c>
<c>20</c> <c>4</c> <c>3</c> <c>4</c> <c>43</c>
<c>20</c> <c>8</c> <c>2</c> <c>0</c> <c>22</c>
<c>32</c> <c>1</c> <c>9</c> <c>7</c> <c>265</c>
<c>32</c> <c>2</c> <c>5</c> <c>6</c> <c>133</c>
<c>32</c> <c>4</c> <c>3</c> <c>4</c> <c>67</c>
<c>32</c> <c>8</c> <c>2</c> <c>0</c> <c>34</c>
<c>48</c> <c>1</c> <c>9</c> <c>7</c> <c>393</c>
<c>48</c> <c>2</c> <c>5</c> <c>6</c> <c>197</c>
<c>48</c> <c>4</c> <c>3</c> <c>4</c> <c>99</c>
<c>48</c> <c>8</c> <c>2</c> <c>0</c> <c>50</c>
<c>64</c> <c>1</c> <c>10</c> <c>6</c> <c>522</c>
<c>64</c> <c>2</c> <c>5</c> <c>6</c> <c>261</c>
<c>64</c> <c>4</c> <c>3</c> <c>4</c> <c>131</c>
<c>64</c> <c>8</c> <c>2</c> <c>0</c> <c>66</c>
</texttable>
</section>

<section title="Example Data for Testing" anchor="testing">
<t>
As with all cryptosystems, implementations of LDWM signatures and
Merkle signatures need to be tested before they are used.  This section contains
sample data generated from the signing and verification operations of software
that implements the algorithms described in this document.
</t>
<section title='Parameters' anchor='test_params'>
<t>
The example contained in this section demonstrates the calculations of LDWM_SHA256_M20_W4
using a Merkle Tree Signature of degree 4 and height 2. This corresponds to the following
parameter values:
</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'>l</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 public/private key pairs of the one-time signatures are unique.
In addition, all LDWM key pairs must be generated in advance in order to calculate
the value of the Merkle public key.
</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' />.</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 SHA-256-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>0x0ba904eae8773b70c75333db4de2f3ac4 &nbsp;&nbsp;5a8ad4ddba1b242f0b3cfc199391dd81c</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='ldwm_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 2) 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 1) 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>