5.2. LMS Private Key

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:

Algorithm 5: Computing an LMS Private Key.

   1. determine h and m from the typecode and Table 2.

   2. compute the array OTS_PRIV[] as follows:
      for ( q = 0; q < 2^h; q = q + 1) {
         S = I || q
         OTS_PRIV[q] = LM-OTS private key with security string S
       }

   3. q = 0

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. Appendix A provides an example of a pseudorandom method for computing an LMS private key.

5.3. LMS Public Key

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

The LMS public key is the string u32str(type) || I || T[1]. Section 7 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 Appendix C.

5.4. LMS Signature

An LMS signature consists of Section 7 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.

• a typecode indicating the particular LMS algorithm,
• the number q of the leaf associated with the LM-OTS signature, as a four-byte unsigned integer in network byte order,
• an LM-OTS signature, and
• 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.

Symbolically, the signature can be represented as u32str(q) || ots_signature || u32str(type) || path[0] || path[1] || ... || path[h-1].

5.4.1. LMS Signature Generation

To compute the LMS signature of a message with an LMS private key, the signer first computes the LM-OTS signature of the message using the leaf number of the next unused LM-OTS private key. The leaf number q in the signature is set to the leaf number of the LMS private key that was used in the signature. Before releasing the signature, the leaf number q in the LMS private key MUST be incremented, to prevent the LM-OTS private key from being used again. If the LMS private key is maintained in nonvolatile memory, then the implementation MUST ensure that the incremented value has been stored before releasing the signature.

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

Several useful time/storage tradeoffs are described in the 'Small-Memory LM Schemes' section of [USPTO5432852].

5.5. LMS Signature Verification

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.

Algorithm 6: LMS Signature Verification

 
  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

Algorithm 6b: Computing an LMS Public Key Candidate from a Signature, Message, Identifier, and algorithm typecode

  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

6. Hierarchical signatures

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

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:

• prv[i] is the LMS private key of the i^th level,
• pub[i] is the LMS public key of the i^th level (which includes the identifier I as well as the key value K),
• sig[i] is the LMS signature of the i^th level,

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.

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.

6.1. Key Generation

When an HSS key pair is generated, the key pair for each level MUST have its own identifier.

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 Section 12.1).

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.

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.

6.2. Signature Generation

To sign a message using the private key prv, the following steps are performed:

• 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.
• The message is signed with prv[L-1], and the value sig[L-1] is set to that result.
• 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].
• 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.

In the specific case of L=1, the format of an HSS signature is

   u32str(0) || sig[0]

In the general case, the format of an HSS signature is

   u32str(Nspk) || signed_pub_key[0] || ... || signed_pub_key[Nspk-1] || sig[Nspk]

which is equivalent to

   u32str(Nspk) || sig[0] || pub[1] || ... || sig[Nspk-1] || pub[Nspk] || sig[Nspk].

6.3. Signature Verification

To verify a signature sig and message using the public key pub, the following steps are performed:

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

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.

7. Formats

The signature and public key formats are formally defined using the External Data Representation (XDR) [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:

/* 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;
};

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.

8. Rationale

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.

We adopt the techniques described by Leighton and Micali to mitigate attacks that amortize their work over multiple invocations of the hash function.

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.

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.

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.

The Checksum Section 4.5 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 Section 4.6 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 Section 4.1 and calculated in Appendix B, which indicates the number of bits used in the left-shift operation.

9. History

This is the fifth version of this draft. It has the following changes from previous versions:

Version 05

• Clarified the L=1 specific case.
• Extended the parameter sets to include an H=25 option
• A large number of corrections and clarifications
• 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.

Version 04

• 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)
• 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.
• Modified the XDR of an HSS signature not to use an array of LM signatures; LM signatures are variable length, and XDR doesn't support arrays of variable length structures.
• 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

Previous versions

• 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.
• The Hierarchical Signature Scheme was generalized slightly so that it can use more than two levels.
• 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.

This section is to be removed by the RFC editor upon publication.

10. IANA Considerations

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:

• a short name, such as "LMS_SHA256_M32_H10",
• a positive number, and
• a reference to a specification that completely defines the signature method test cases that can be used to verify the correctness of an implementation.

Requests to add an entry to the registry MUST include the name and the reference. The number is assigned by IANA. Submitters SHOULD have their requests reviewed by the IRTF Crypto Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants that are unfamiliar with IANA processes should visit http://www.iana.org.

The numbers between 0xDDDDDDDD (decimal 3,722,304,989) and 0xFFFFFFFF (decimal 4,294,967,295) inclusive, will not be assigned by IANA, and are reserved for private use; no attempt will be made to prevent multiple sites from using the same value in different (and incompatible) ways [RFC2434].

The LM-OTS registry is as follows.

   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

x_q[j] = H(I || u32str(q) || SEED || u16str(j) || D_PRG).

  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

  for ( i = 0; i < 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)

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

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

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