Network Working Group J. Harvey
InternetDraft B. Kaliski
Intended status: Informational A. Fregly
Expires: 14 December 2024 S. Sheth
Verisign Labs
12 June 2024
Merkle Tree Ladder (MTL) Mode Signatures
draftharveycfrgmtlmode03
Abstract
This document provides an interoperable specification for Merkle tree
ladder (MTL) mode, a technique for using an underlying signature
scheme to authenticate an evolving series of messages. MTL mode can
reduce the signature scheme's operational impact. Rather than
signing messages individually, the MTL mode of operation signs
structures called "Merkle tree ladders" that are derived from the
messages to be authenticated. Individual messages are then
authenticated relative to the ladder using a Merkle tree
authentication path and the ladder is authenticated using the public
key of the underlying signature scheme. The size and computational
cost of the underlying signatures are thereby amortized across
multiple messages, reducing the scheme's operational impact. The
reduction can be particularly beneficial when MTL mode is applied to
a postquantum signature scheme that has a large signature size or
computational cost. As an example, the document shows how to use MTL
mode with SPHINCS+ (and the SLHDSA subset specified in the draft
FIPS 205), the stateless hashbased signature scheme selected by NIST
for standardization. Like other Merkle tree techniques, MTL mode's
security is based only on cryptographic hash functions, so the mode
is quantumsafe based on the quantumresistance of its cryptographic
hash functions.
Status of This Memo
This InternetDraft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
Drafts is at https://datatracker.ietf.org/drafts/current/.
Harvey, et al. Expires 14 December 2024 [Page 1]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
This InternetDraft will expire on 14 December 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
licenseinfo) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 5
2. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Operators . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Functions . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Algorithm Style . . . . . . . . . . . . . . . . . . . . . 7
3. General Model . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Parameters, Cryptographic Functions and Address
Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Domain separation and modes of operation . . . . . . . . 10
4.2. Security parameter . . . . . . . . . . . . . . . . . . . 11
4.3. Randomized message digest function (H_msg_mtl) . . . . . 11
4.4. Pseudorandom function (PRF_msg) . . . . . . . . . . . . . 12
4.5. Tweakable hash functions (F and H) . . . . . . . . . . . 12
4.6. Address scheme . . . . . . . . . . . . . . . . . . . . . 13
4.7. Cryptographic separation and message index association for
H_msg_mtl and PRF_msg . . . . . . . . . . . . . . . . . . 14
5. Computing Data Values from Messages . . . . . . . . . . . . . 15
5.1. Signer Operations . . . . . . . . . . . . . . . . . . . . 15
5.2. Verifier Operations . . . . . . . . . . . . . . . . . . . 16
6. MTL Node Sets . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Seeds and Series Identifiers . . . . . . . . . . . . . . 17
6.2. Node Sets . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Leaf Nodes . . . . . . . . . . . . . . . . . . . . . . . 18
Harvey, et al. Expires 14 December 2024 [Page 2]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
6.4. Internal Nodes . . . . . . . . . . . . . . . . . . . . . 18
6.5. Ladders . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.6. Authentication Paths . . . . . . . . . . . . . . . . . . 21
6.7. Backward Compatibility . . . . . . . . . . . . . . . . . 22
7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Ladder . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Rung . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Authentication Path . . . . . . . . . . . . . . . . . . . 25
8. MTL Node Set Operations . . . . . . . . . . . . . . . . . . . 26
8.1. MTL Node Set Object . . . . . . . . . . . . . . . . . . . 27
8.2. MTL Node Set Hash Operations . . . . . . . . . . . . . . 27
8.2.1. Hashing a Data Value to Produce a Leaf Node Hash Value
(Function: hash_leaf) . . . . . . . . . . . . . . . . 27
8.2.2. Hashing Two Child Nodes to Produce an Internal
Node . . . . . . . . . . . . . . . . . . . . . . . . 28
8.3. Initializing a MTL Node Set (Function: mtl_initns) . . . 29
8.4. Appending a Data Value to a MTL Node Set (Function:
mtl_append) . . . . . . . . . . . . . . . . . . . . . . . 30
8.5. Computing an Authentication Path (Function:
mtl_authpath) . . . . . . . . . . . . . . . . . . . . . . 31
8.6. Computing the Merkle Tree Ladder for a Node Set (Function:
mtl_ladder) . . . . . . . . . . . . . . . . . . . . . . . 32
8.7. Selecting a Ladder Rung (Function: mtl_rung) . . . . . . 33
8.8. Verifying an Authentication Path (Function:
mtl_verify) . . . . . . . . . . . . . . . . . . . . . . . 34
9. Signing and Verifying Messages in MTL Mode . . . . . . . . . 36
9.1. Signing Messages . . . . . . . . . . . . . . . . . . . . 36
9.2. Verifying Signatures . . . . . . . . . . . . . . . . . . 38
9.3. Ladder identifiers . . . . . . . . . . . . . . . . . . . 39
9.4. Full Signatures . . . . . . . . . . . . . . . . . . . . . 40
9.5. Condensed Signatures . . . . . . . . . . . . . . . . . . 41
9.6. Signed Ladders . . . . . . . . . . . . . . . . . . . . . 41
10. SPHINCS+ in MTL Mode . . . . . . . . . . . . . . . . . . . . 42
10.1. SHAKE instantiations . . . . . . . . . . . . . . . . . . 44
10.1.1. Randomized message digest function (H_msg_mtl) . . . 45
10.1.2. Pseudorandom function (PRF_msg) . . . . . . . . . . 45
10.1.3. Tweakable hash functions (F and H) . . . . . . . . . 45
10.2. SHA2 instantiations . . . . . . . . . . . . . . . . . . 46
10.2.1. Randomized message digest function (H_msg_mtl) . . . 46
10.2.2. Pseudorandom function (PRF_msg) . . . . . . . . . . 46
10.2.3. Tweakable hash functions (F and H) . . . . . . . . . 46
11. Calculating Maximum Signature Sizes . . . . . . . . . . . . . 47
12. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 47
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
14. Security Considerations . . . . . . . . . . . . . . . . . . . 48
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
15.1. Normative References . . . . . . . . . . . . . . . . . . 51
15.2. Informative References . . . . . . . . . . . . . . . . . 52
Harvey, et al. Expires 14 December 2024 [Page 3]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 54
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction
This document provides an interoperable specification for Merkle tree
ladder (MTL) mode [MTLMODE], a technique for using a signature
scheme to authenticate an evolving series of messages that
potentially can reduce the operational impact of the signature
scheme.
MTL mode is a different way of using an underlying signature scheme.
Instead of signing individual messages directly, MTL mode signs
structures called "Merkle tree ladders" that are derived from the
messages to be authenticated. Individual messages are then
authenticated relative to the ladder using a Merkle tree
authentication path (also called a Merkle proof). The operational
impact of the signatures on the ladders is thus amortized across
multiple messages. The remaining permessage cost consists of the
overhead of computing and using the ladders and authentication paths.
The operational benefits of MTL mode are most evident in scenarios
where verifiers are interested in a subset of messages among a large,
evolving series of messages. Examples include authenticating web
PublicKey Infrastructure certificates [RFC5280], Domain Name System
Security Extensions (DNSSEC) records [RFC4033] and signed certificate
timestamps [RFC9162]. MTL mode is not well suited to scenarios where
a verifier is interested in authenticating a single, newly generated
message. An example is a Transport Layer Security transcript hash
[RFC8446]. In such scenarios, a ladder would need to be signed and
verified for every message processed, so the operational impact would
not be reduced.
Harvey, et al. Expires 14 December 2024 [Page 4]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
The mode is intended primarily for use with postquantum signature
schemes where the reduction of operational impact can be significant
given their relatively large signature sizes. As an initial example,
this document shows how to use MTL mode with SPHINCS+, a stateless
hashbased postquantum signature scheme selected by NIST for
standardization [SPHINCSPLUS] (and the SLHDSA subset specified in
the draft [FIPS205IPD]). The design decision is motivated by three
considerations: (1) SPHINCS+ also is based on Merkle trees, and thus
already has internal functions for computing leaf nodes and internal
nodes; (2) SPHINCS+ has a relatively large signature size and
computational cost, and therefore can benefit significantly from the
reductions offered by MTL mode; and (3) hashbased techniques are
well understood and offer a conservative choice for longterm
security, alongside newer techniques from other families such as
latticebased cryptography. Future updates to this document may
support other signature schemes.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Preliminaries
2.1. Definitions
Node Set A set of nodes, each of which is part of a union of tree
structures either as a leaf node whose value is the hash of a
single data value, or an internal node whose value is the hash of
two child nodes. The node set is acyclic, i.e., every node is
either a leaf node or the ancestor of two or more leaf nodes, and
no node is an ancestor of itself. Every node set has one or more
root nodes, i.e., nodes that have no ancestors.
Rung A node from a node set that can be used to authenticate one or
more leaf nodes within that node set.
Ladder A collection of one or more rungs that can be used to verify
an authentication path.
Authentication Path The set of sibling hash values from a leaf hash
value to a rung
Message A set of bytes that are intended to be signed and later
verified.
Harvey, et al. Expires 14 December 2024 [Page 5]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
2.2. Operators
Standard order of operations is assumed throughout this document.
The following mathematical operators are used:
** : a ** b denotes the value of a raised to the power of b
* : a * b denotes the product of a multiplied by b
/ : a / b denotes the quotient of a divided by b
+ : a + b denotes the sum of a and b when a and b are numbers
 : a  b denotes the difference of a and b
= : a = b denotes assigning the value of b to a
The following bitwise operators are used:
& : a & b denotes the bitwise AND of the unsigned integers a and b
 : a  b denotes the bitwise OR of the unsigned integers a and b
~ : ~a denotes the bitwise NOT of the unsigned integer a
>> : a >> i denotes a right bit shift (nonrotating) of a by i bit
positions to the right.
<< : a << i denotes a left bit shift (nonrotating) of a by i bit
positions to the left.
The following comparison operators are used:
== : a == b denotes the comparison between a and b to see if the
two values are equal
<= : a <= b denotes the comparison between a and b to see if a is
less than or equal to b
>= : a >= b denotes the comparison between a and b to see if a is
greater than or equal to b
!= : a != b denotes the comparison between a and b to see if a is
not equal to b
The following array notation is used:
The notation A[i] represents the ith element of array A.
The following byte string notation is used:
+ : a + b denotes the concatenation of values a and b when a and b
are byte strings.
2.3. Functions
Given an unsigned integer x or a message byte string a, the following
functions are defined:
Harvey, et al. Expires 14 December 2024 [Page 6]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
lsb(x) returns the position of the least significant bit of x, where
bit positions start at 1 and lsb(0) = 0.
msb(x) returns the position of the most significant bit of x.
bit_width (x) returns the number of 1 value bits in x. This
corresponds to the popcnt instruction on Intel/AMD processors and the
__builtin_popcount function in gcc.
octet(x) returns a single byte with value x (assuming 0 <= x <= 255).
OLEN(a) returns the length in bytes of a.
Example Function Outputs:
++++++
 x  representation  lsb  msb  bit_width 
++++++
 0  00000000 + 0  0  0 
 1  00000001 + 1  1  1 
 2  00000010 + 2  2  1 
 3  00000011 + 1  2  2 
 4  00000100 + 3  3  1 
 5  00000101 + 1  3  2 
 6  00000110 + 2  3  2 
 7  00000111 + 1  3  3 
++++++
2.4. Algorithm Style
The data structures and algorithms defined in this document are
written to be runnable Python 3 code. The following styles have been
applied to further make the code easy to read and follow:
* Classes and data structures are written in all uppercase (e.g.
MTLNS)
* Constant values are also written as all uppercase with _
separating words (e.g. MTL_SIG_CONDENSED)
* Variables are written in all lowercase with _ separating words as
needed (e.g. left_hash or tree)
* Functions are written in all lower case and proceeded by a comment
block that highlights the input and output parameters.
3. General Model
The general model for MTL mode involves the following exchanges
between a signer and a verifier. The signer is assumed to have a
private key for an underlying signature scheme and the verifier is
assumed to have the corresponding public key.
Harvey, et al. Expires 14 December 2024 [Page 7]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
1. The signer maintains a dynamic data structure called a Merkle
node set. The leaf nodes of the node set correspond to the
messages that are being "signed" for later authentication and the
internal nodes of the node sets are the hashes of two child
nodes. Similar to a Merkle tree structure, ancestors
authenticate or "cover" their descendants. A Merkle node set is
more general than a Merkle tree in that more than one node can be
a root node (i.e., a node without ancestors). For instance, a
Merkle node set could include multiple trees.
2. As the node set evolves, the signer occasionally selects a set of
nodes from the node set that collectively cover all the leaf
nodes. Such a set is called a "ladder" and each node within the
set is called a "rung." The rungs are selected according to a
"binary rung strategy" where each rung is the root of a perfect
binary tree (see Section 6.5).
3. The signer signs each ladder with the private key of the
underlying signature scheme. The signature on the ladder is the
"MTL mode signature" of the set of messages covered by the
ladder.
4. For each message of interest to a verifier, the signer provides
the verifier a Merkle authentication path from the leaf node
corresponding to the message to a rung in the thencurrent
ladder. Similar to a Merkle tree structure, the authentication
path includes the sibling hashes on the path from the leaf node
to a rung on the ladder that covers the leaf node.
5. If the verifier has a ladder that is "compatible" with the
authentication path, the verifier verifies the authentication
path on the message relative to the ladder.
6. If not, the verifier requests the signed ladder that the
authentication path was computed relative to. (Alternatively,
the verifier may request a "full" signature on the message that
includes both the authentication path and the signed ladder that
it is computed relative to, which could be the current ladder.
See Section 9.4 for a description of a full signature.)
7. The signer provides the signed ladder. (Or, alternatively, the
signer provides a full signature including the authentication
path together with a signed ladder.)
8. The verifier verifies the signature on the signed ladder and
returns to Step 5.
The model can reduce the operational impact of the underlying
signature scheme in two main ways. First, per Steps 2 and 3, the
signer signs ladders only as needed, not necessarily every time a
message is added to a message series. The signer thus potentially
makes many fewer calls to the underlying signature generation
operation and stores fewer signatures than if the messages were
signed individually. Second, per Steps 6, 7 and 8, the verifier
obtains and verifies signatures on ladders only as needed, not
Harvey, et al. Expires 14 December 2024 [Page 8]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
necessarily every time a message is authenticated. The signer thus
potentially sends fewer signatures, and the verifier stores and
verifies fewer signatures, than if the messages were signed
individually.
4. Security Parameters, Cryptographic Functions and Address Scheme
MTL mode signatures are dependent on an underlying signature scheme,
requiring proper domain separation and alignment of the security
parameters and functions.
MTL mode, like prehashing, requires domain separation from the
underlying signature scheme. Methods for MTL mode domain separation
are defined in Section 4.1, following a scheme that is similar to
what is specified by NIST in FIPS 204 and FIPS 205.
Because SPHINCS+ is the initial recommended underlying signature
scheme for MTL mode, this document specifies MTL mode using the
SPHINCS+ security parameter and abstract cryptographic functions that
are substantially the same as the ones in [SPHINCSPLUS]. This
includes the subset of instantiations that are defined for SLHDSA in
draft [FIPS205IPD]. The document also uses an extended version of
the [SPHINCSPLUS] address scheme with additional address types. One
goal of this approach is to make it easier for developers who already
have a SPHINCS+ implementation to build MTL mode operations. Another
goal is to makes it easier to ensure that MTL mode operations are
cryptographically separated from SPHINCS+'s internal operations.
The cryptographic parameter is defined in Section 4.2. Domain
separation and prehashing as they relate to MTL mode are discussed
in Section 4.1. The cryptographic functions are defined in
Section 4.3, Section 4.4 and Section 4.5. The address scheme is
defined in Section 4.6. Finally, cryptographic separation and
message index association are discussed in Section 4.7.
In an implementation, the parameter needs to be instantiated with an
actual value and the abstract functions need to be instantiated with
actual functions. Recommended instantiations when the underlying
signature scheme is SPHINCS+ are given in Section 10. Recommended
instantiations for other underlying signature schemes may be added in
updates to this document.
In the following, notation  indicates concatenation of byte strings
for consistency with SPHINCS+, in contrast to the + notation used for
byte string concatenation elsewhere in the document.
Harvey, et al. Expires 14 December 2024 [Page 9]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
4.1. Domain separation and modes of operation
[FIPS204IPD] and [FIPS205IPD] both propose two ways to use their
underlying signature schemes: "pure," where a message is input
directly to the underlying signature scheme, and "prehash," where a
hash of the message is the input. Both also take an optional
applicationspecified context string as input. MTL mode can be
modeled as a third "mode of operation," where a ladder derived from
one or more messages is the input. Expanding on the April 19, 2024
prehashing proposal by NIST [NISTPREHASHUPDATE], the input to the
underlying signature scheme in this version of the document is
formatted as follows:
octet(MTL_LADDER_SEP)  octet(OLEN(ctx)) 
ctx  OID_MTL  ladder
where:
* MTL_LADDER_SEP is the integer 129 (a new domain separator value
that provides easy visual separation in hexadecimal from the
identifiers 0 and 1 in NIST's proposal)
* ctx is an applicationspecified context string at most 255 octets
(bytes) long (default is the empty string)
* OID_MTL is the DER encoding of the object identifier of the
selected instantiation of MTL mode (see Section 10 for the list of
instantiations; the object identifiers are TBD)
* ladder is the Merkle tree ladder being signed or verified
The format above separates MTL mode inputs from pure inputs to the
underlying signature scheme (which would have a first byte of 0) and
from other prehash inputs (which would have a first byte of 1). The
concatenation of the first four strings in the format (i.e., the
strings preceding the ladder) is referred to as the "MTL ladder
domain separator."
For domain separation between calls made by MTL mode operations and
those made by the underlying signature scheme (in the case of
SPHINCS+; see Section 4.7), the inputs to H_msg_mtl and PRF_msg in
calls made by MTL mode operations are formatted as follows:
octet(MTL_MSG_SEP)  octet(OLEN(ctx))  ctx  value
where:
* MTL_MSG_SEP is the integer 128 (a counterpart to MTL_LADDER_SEP's
129 above)
* ctx is an applicationspecified context string at most 255 octets
(bytes) long (default is the empty string)
Harvey, et al. Expires 14 December 2024 [Page 10]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
* value is the rest of the value being input to the function
The concatenation of the first three strings in the format (i.e., the
strings preceding the value) is referred to as the "MTL message
domain separator."
FOR DISCUSSION: Expanding on the pure and prehash domain separator
formats is intended to make it easier for implementations of FIPS 204
and FIPS 205 to be extended to support MTL mode in a way that
separates MTL mode from the pure and prehash modes. However, the
approach introduces a new first byte value and new OIDs that
implementations might not initially recognize. An alternative is to
reuse the proposed prehash domain separator format and consider MTL
mode itself as a more complex form of prehashing. Instead of a new
byte, the alternative only introduces new OIDs. However,
implementations might only expect OIDs that are associated with NIST
approved hash functions, not MTL mode. Prehashing remains an active
discussion topic on the NIST PQC mailing list as of this writing, and
further updates may be made to this document as is appropriate.
4.2. Security parameter
MTL mode has one security parameter, the size in bytes of hash
values, denoted n. The security parameter SHOULD be at least 16.
Typical values of n are 16, 24 and 32 (see Section 10). The security
parameter affects the difficulty of breaking MTL mode (see
Section 14).
4.3. Randomized message digest function (H_msg_mtl)
MTL mode makes use of a variant of the randomized message digest
function (i.e., keyed hash function) H_msg defined in SPHINCS+:
* H_msg_mtl(R_mtl, PK.seed, PK.root, M) > md maps a nbyte
randomizer, a nbyte public seed, a nbyte public root and a
variablelength message to a nbyte hash value md.
H_msg_mtl differs from SPHINCS+'s H_msg in that its output hash value
is n bytes long rather than m bytes long (where m is a separate
parameter in SPHINCS+). The inputs to H_msg_mtl have the following
meanings:
* R_mtl is the randomizer for the message digest operation
* PK.seed the public seed from the public key
* PK.root is the public root from the public key
* M is the message being processed.
Harvey, et al. Expires 14 December 2024 [Page 11]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
H_msg_mtl is used for computing data values from messages in MTL mode
(see Section 5.1 and Section 5.2). (Note that when H_msg_mtl is
called in these sections, M is the message being signed prepended
with a MTL message domain separator  see Section 4.7 for
discussion.)
4.4. Pseudorandom function (PRF_msg)
MTL mode also makes use of pseudorandom function PRF_msg defined in
SPHINCS+:
* PRF_msg(SK.prf, OptRand, M) > R_mtl maps a nbyte secret PRF key,
a nbyte optional random value, and a variablelength message to a
nbyte randomizer R_mtl.
The inputs to PRF_msg have the following meanings:
* SK.prf is the secret PRF key from the private key.
* OptRand depends on whether an implementation wants deterministic
signing. If it does, then OptRand SHOULD be a fixed value, e.g.,
all 0s or PK.seed. (The SPHINCS+ specification suggests both
options in different places for its internal use of OptRand.) If
not, then OptRand MUST be a randomly generated value.
* M is the message being processed.
PRF_msg is used for computing randomizers for hashing messages in MTL
mode (see Section 5.1 and Section 5.2). (Note that when PRF_msg is
called in these sections, M is an ADRS value prepended with a domain
separator, optionally followed by the message being signed  see
Section 4.7 for discussion.)
4.5. Tweakable hash functions (F and H)
MTL mode makes use of the tweakable hash functions F and H defined in
SPHINCS+:
* F(PK.seed, ADRS, M_1) > md maps a nbyte public seed, a 32byte
address value and a nbyte message value to a nbyte hash value
* H(PK.seed, ADRS, M_1  M_2) > md maps a nbyte public seed, a
32byte address value and the concatenation of two nbyte message
values to a nbyte hash value
The inputs to F and H have the following meanings:
Harvey, et al. Expires 14 December 2024 [Page 12]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
* PK.seed is the public seed from the public key. This value is a
"tweak" to the hash function that separates uses of the function
with different public keys (assuming different public keys have
different public seeds, as they almost always will if the public
seeds are generated at random).
* ADRS is the address associated with the call to the function.
This value is another "tweak" that separates uses of the function
for different purposes.
* M_1 (input to F) is a nbyte value being hashed.
* M_1  M_2 (input to H) is the concatenation of two nbyte values
being hashed together.
F is used for computing a leaf node from a data value in MTL mode
(see Section 8.2.1). H is used for computing an internal node hash
value from two child node hash values (see Section 8.2.2).
4.6. Address scheme
MTL mode extends the address scheme for function inputs defined in
SPHINCS+, adding four address types.
As in SPHINCS+, the address is an eightword (32byte) value. The
fifth word (byte positions 1720) is the address type.
This document assigns identifiers 1618 for new address types. The
assignment provides easy visual separation in hexadecimal from the
identifiers 06 used by SPHINCS+. The constants MTL_MSG, MTL_DATA,
and MTL_TREE provide a descriptive alternative to the numbers.
For all three types, the first and second words MUST be 0 and the
third and fourth words MUST be the series identifier SID associated
with the MTL mode operation, padded on the left. The sixth, seventh
and eighth words depend on the address type. Index values are
represented as 4byte unsigned integers in big endian notation.
* MTL Message Hash (type MTL_MSG = 16). This type is used in the
address value that is prepended to a message when calling PRF_msg
to compute a randomizer or when calling H_msg_mtl to compute a
data value from a message. For this type, the sixth and seventh
words MUST be 0 and the eighth word MUST be the message index
(i.e., the leaf index of the corresponding leaf node).
* MTL Data Value (type MTL_DATA = 17). This type is used when
calling F to compute a leaf node hash value from a data value.
For this type, the sixth and seventh words MUST be 0 and the
eighth word MUST be the leaf index.
* MTL Tree (type MTL_TREE = 18). This type is used when calling H
to compute an internal node hash value from two child node hash
values. For this type, the sixth word MUST be 0, the seventh word
Harvey, et al. Expires 14 December 2024 [Page 13]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
MUST be the left index associated with the internal node and the
eighth word MUST be the right index associated with the internal
node.
 Byte Positions 
+++++++++
 Address Type 1458 9161720212425282932
+++++++++
 MTL Message Hash  0  0  SID  16  0  0 MsgID
+++++++++
 MTL Data Value  0  0  SID  17  0  0 MsgID
+++++++++
 MTL Tree  0  0  SID  18  0  LeftRight
+++++++++
Address values are represented with the ADRS class.
4.7. Cryptographic separation and message index association for
H_msg_mtl and PRF_msg
The security proof for MTL mode in [MTLMODE] assumes that calls to
the function for computing data values from messages, i.e., to
H_msg_mtl here, are cryptographically separated from calls made by
SPHINCS+'s internal operations. In addition, the security proof
assumes that calls to this function also include the message index as
input.
For the tweakable hash functions in SPHINCS+, cryptographic
separation and message index association are achieved by taking an
address value as input. However, H_msg in SPHINCS+ doesn't take an
address value as input, and for consistency, neither does H_msg_mtl.
This document takes the following approach to achieve cryptographic
separation and message index association for calls to H_msg and
H_msg_mtl:
* When calling H_msg_mtl to compute a data value from a message, see
Section 5.1 and Section 5.2, a MTL message domain separator and an
address value of type MTL_MSG are prepended to the message, where
the address value includes the message index
* When calling the underlying signature scheme to sign a ladder or
verify a signature on a ladder (see Section 4.1), a MTL ladder
domain separator is prepended to the ladder
Harvey, et al. Expires 14 December 2024 [Page 14]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
This document takes a comparable approach to achieve cryptographic
separation and message index association for calls to PRF_msg. (Note
that calls to PRF_msg from the MTL mode operations only take the
domain separator and the address value in the input, not the
message.)
Assuming that the underlying signature scheme passes the message to
be signed directly to H_msg, as SPHINCS+ does, the calls to H_msg_mtl
from the MTL mode operations and to H_msg from SPHINCS+ will involve
values of M whose first bytes differ, providing cryptographic
separation between calls by the MTL mode operations and by SPHINCS+.
A comparable observation applies to calls to PRF_msg.
5. Computing Data Values from Messages
In MTL mode, variablelength messages are converted to fixedlength
data values that can be processed by the MTL node set operations in
the next section.
The conversion process involves a randomized message digest
operation. The signer computes the randomizer and sends it to the
verifier along with other information needed to authenticate the
message.
The computation of the randomizer varies depending on whether the
signer selects deterministic hashing or randomized hashing. (The
choice follows a similar approach to SPHINCS+.)
5.1. Signer Operations
A MTL mode signer starts with a message M, a context string ctx, a
series identifier SID, and a message index MsgID and computes a
randomizer R_mtl and a data value with the following steps.
* Form an address value ADRS of type MTL_MSG from the series
identifier and the message index as described in Section 4.6.
* Format a MTL message domain separator sep from the context string
as follows:
sep = octet(MTL_MSG_SEP)  octet(OLEN(ctx))  ctx
* With deterministic hashing, let OptRand be the public seed PK.seed
* Generate a randomizer R_mtl using a secure random generator
[RFC4086]. An implementation MAY use the following steps:
 With randomized hashing, let OptRand be a random nbyte value
 Compute a randomizer by applying PRF_msg to a secret PRF key,
SK.prf, the optional random value and the address value
prepended with the domain separator
Harvey, et al. Expires 14 December 2024 [Page 15]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
R_mtl = PRF_msg(SK.prf, OptRand, sep  ADRS)
An implementation MAY either use the same or a different SK.prf value
as is used in the underlying signature scheme. In either case, the
SK.prf value MUST have been generated using a secure random generator
and MUST be kept secret, e.g., as part of the private key. Using the
same SK.prf value avoids the need to generate and manage an
additional secret. However, using a different SK.prf value can be
advantageous if the underlying signature scheme is implemented in a
security module and the MTL mode operations are implemented outside
the security module and do not have access to the underlying
signature schemes SK.prf value.
An implementation MAY additionally include the message M in the input
to the PRF_msg call by appending it to ADRS, i.e., by passing sep 
ADRS  M as the third argument. However, this approach involves an
additional pass over the message, which can be disadvantageous if the
message is long.
* Compute the data value by applying H_msg_mtl to the randomizer,
the public seed, the public root and the message prepended with
the same address value
data_value = H_msg_mtl(R_mtl, PK.seed, PK.root, sep  ADRS  M)
5.2. Verifier Operations
A MTL mode verifier starts with a message M, a randomizer R_mtl, a
context string ctx, a series identifier SID and a message index MsgID
and recomputes the data value with the following steps.
* Form an address value ADRS of type MTL_MSG from the series
identifier and the message index as described in Section 4.6.
* Format a MTL message domain separator sep from the context string
as follows:
sep = octet(MTL_MSG_SEP)  octet(OLEN(ctx))  ctx
* Compute the data value by applying H_msg_mtl to the randomizer,
the public seed, the public root and the message prepended with
the domain separator and the address value:
data_value = H_msg_mtl(R_mtl, PK.seed, PK.root, sep  ADRS  M)
Harvey, et al. Expires 14 December 2024 [Page 16]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
6. MTL Node Sets
The core functionality that enables MTL mode is a set of hashbased
nodes organized in an expanding treelike structure. This allows for
appending data values to an expanding data series, computing ladders
and computing authentication paths from data values to ladder rungs.
MTL node set operations provide the building blocks for
authenticating messages when a signature scheme is operated in in MTL
mode.
A MTL node set authenticates a series of data values. Each data
value in the series has a unique index, a nonnegative integer. In
the MTL mode operations in this document, the index starts at 0 and
is incremented by 1 after each new data value is appended. A data
value is computed from a message to be authenticated via a randomized
message digest operation, as described in the previous section.
Three data structures supporting MTL node sets are given in Section 7
and six MTL node set operations are given in Section 8. This section
provides a general overview of the concepts behind those techniques.
6.1. Seeds and Series Identifiers
The hash operations in the MTL node set operations take a public seed
and a series identifier input. The public seed separates the use of
the hash operations with different public keys (assuming different
public keys have different public seeds). The series identifier
separates the use of the hash operations for different series for
data values with the same public key.
Both the public seed and the series identifier are nbyte values
where n is the security parameter.
6.2. Node Sets
A MTL node set has zero or more nodes each of the form where:
* L is the node's left index, a nonnegative integer
* R is the node's right index, a nonnegative integer
* V is the node's hash value
The pair (L,R) is the node's index pair. A node set MUST NOT have
more than one node with a given index pair.
The node with index pair (L,R) authenticates the data values with
indexes between L and R inclusive. If L = R, the node is a leaf node
(Section 6.3). If L < R, then it is an internal node (Section 6.4).
Harvey, et al. Expires 14 December 2024 [Page 17]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
6.3. Leaf Nodes
A leaf node is a node where L = R. It has no child nodes. Its hash
value is computed as
V = hash_leaf(seed, sid, L, data_value)
where hash_leaf is a hash function defined in Section 8.2.1, seed and
sid are the public seed and series identifier and data_value is the
data value associated with this leaf index.
Including the leaf index as an input to hash_leaf separates the use
of the hash function for different leaf nodes.
A leaf node with a given index authenticates the data value with the
corresponding index. It follows that if a node set has a leaf node
with a given index, then the data series MUST have a data value with
the same index.
6.4. Internal Nodes
An internal node is a node where L < R.
An internal node has two child nodes, called a left child and a right
child. Its hash value is computed as
V = hash_int(seed, sid, L, R, left_hash, right_hash)
where hash_int is a hash function defined in Section 8.2.2, seed and
sid are the public seed and the series identifier, left_hash is the
left child's hash value and right_hash is the right child's hash
value.
Including the left and right indexes as inputs to hash_int separates
the use of the hash function for different internal nodes.
The left and right children are the nodes with index pairs (L,M1)
and (M,R) respectively where M, the middle index, is the unique
integer between L+1 and R that is divisible by the largest power of
two. The child index ranges are thus a partition of the internal
node's index range. The middle index can be computed as follows:
power = msb(RL)
M = R  mod(R, 2^(power+1))
if(M <= L):
M = R  mod(R, 2^power)
Harvey, et al. Expires 14 December 2024 [Page 18]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
An internal node with index pair (L,R) authenticates the data values
with indexes between L and R inclusive. It follows that if a node
set has an internal node with an index pair (L,R), then the data
series MUST have data values with indexes L through R. In addition,
the node set MUST have nodes with index pairs (L,M1) and (M,R).
The following table gives examples of index pairs for internal nodes
and their left and right child nodes. In the table, a leaf node is
denoted with a single index. For instance, the index 4 is equivalent
to the index pair (4,4).
Internal Node  Left Child  Right Child
(L,R)  (L,M1)  (M,R)
++
(0,3)  (0,1)  (2,3)
(4,5)  4  5
(0,5)  (0,3)  (4,5)
(0,31)  (0,15)  (16,31)
(0,2)  (0,1)  2
6.5. Ladders
A ladder is a subset of nodes that is used to authenticate data
values. Each node in the ladder is called a rung.
In the MTL mode operations in this document, the subset is selected
according to what is called the binary rung strategy. In this
strategy, the index pairs for the rungs are based on the binary
representation of the number of data values in the data series.
The rungs in the binary rung strategy are selected as follows. Let N
be the number of data values in the data series, let B be the number
of 1s bits in the binary representation of N. N can then be
represented as the sum of B distinct binary powers.
N = 2^v_1 + 2^v_2 + ... + 2^(v_B)
where v_1 > v_2 > ... > v_B are the bit positions of the 1s bits in
the binary representation. The first rung has index pair
(0,2^v_11); it is the apex of a perfect binary tree of height v_1
and authenticates the first 2^v_1 data values. The next rung has
index pair (2^(v_1,2)v_1+2^v_21); it is the apex of a perfect binary
tree of height v_2 and authenticates the next 2^v_2 data values. The
process continues until the Bth rung, which has index pair
(N2^v_B,N1) and authenticates the last 2^v_B data values.
Harvey, et al. Expires 14 December 2024 [Page 19]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
A rung is said to cover the data values it authenticates, and a
ladder is said to cover the data values that its rungs collectively
authenticate. The ladder just described thus covers all N data
values in the node set.
(Another way of visualizing the rungs is to consider the first rung
as the apex of the largest perfect binary tree that can be formed
from the data values, starting from the left; the second rung as the
apex of the largest perfect binary tree than can be formed over the
remaining data values; and so on. The sizes of the trees decrease
from left to right.)
(The binary rung strategy can be contrasted with the typical "single
rung strategy" employed with Merkle trees, where a single rung of a
node set is used to authenticate data values, i.e., the root node
(0,N1). When N is a power of 2, the singlerung strategy and the
binaryrung strategy are the same.
When the Nth data value is added to the node set, v_B+1 new nodes
need to be computed to update the ladder: the leaf node with index
(N1,N1) and the v_B internal nodes leading from the leaf node to
the new ladder rung (N2^v_B,N1). The first B1 ladder rungs in the
new ladder are the same as in the previous ladder. Because 2^v_B is
at most N, the number of new nodes computed is logarithmic in N,
similar to ordinary Merkle tree constructions. Moreover, every node
computed in the process is the apex of a perfect binary tree.
The minimum number of rungs in a ladder computed with the binary rung
strategy is 1, in the case that the number of leaf nodes N is a power
of 2. The maximum number is the least integer greater than or equal
to log2(N), or equivalently ceiling(log2(n)). The actual number is
bit_width(N).
The following table gives examples of ladders for values of N up to
14. As in the previous table, a leaf node is designated with a
single index.
Harvey, et al. Expires 14 December 2024 [Page 20]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
Number of Data Values  Ladder Rungs
N 

1  0
2  (0,1)
3  (0,1) 2
4  (0,3)
5  (0,3) 4
6  (0,3) (4,5)
7  (0,3) (4,5) 6
8  (0,7)
9  (0,7) 8
10  (0,7) (8,9)
11  (0,7) (8,9) 10
12  (0,7) (8,11)
13  (0,7) (8,11) 12
14  (0,7) (8,11) (12,13)
15  (0,7) (8,11) (12,13) 14
16  (0,15)
17  (0,15) 16
18  (0,15) (16,17)
19  (0,15) (16,17) 18
The following figure shows a node set with 14 nodes where the rungs
are computed according to the binary rung strategy. The internal
node hash function is denoted H and the leaf node hash function is
not shown. The rungs are marked with asterisks (*).
(0,7)*

H
// \\
(0,3) (4,7) (8,11)*
  
H H H
// \\ // \\ // \\
(0,1) (2,3) (4,5) (6,7) (8,9) (10,11) (12,13)*
      
H H H H H H H
/ \ / \ / \ / \ / \ / \ / \
0 1 2 3 4 5 6 7 8 9 10 11 12 13
6.6. Authentication Paths
An authentication path is the set of sibling node hash values
encountered along the path from a leaf node to a target rung that
covers a data value.
Harvey, et al. Expires 14 December 2024 [Page 21]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
Target rungs can be any of the successive ancestors of the leaf node
in the node set. Because each rung is the apex of a perfect binary
tree, the sibling nodes encountered follow the structure of the
binary tree.
For example, in the figure above, the sibling nodes encountered in
the path from leaf node 6 to the rung (0,7) are the nodes with
indexes 7, (4,5) and (0,3). The authentication path for the data
value with index 6 includes the hash values at those nodes. This
data value can be authenticated by recomputing leaf node 6 from the
data value using hash_leaf, recomputing internal nodes (6,7), (4,7)
and (0,7) from the sibling node hash values and previously computed
hash values using hash_int, and then comparing the result to the rung
hash value.
The minimum number of sibling nodes in an authentication path
computed with the binary rung strategy is 0, in the case that the
leaf node is the last leaf added and the number of leaf nodes N is
odd. The maximum number is the greatest integer less than or equal
to log2(N) , or equivalently floor(log2(N)). The actual number is
bit_width(RL) where (L,R) is the index pair of the rung covering the
leaf node.
6.7. Backward Compatibility
An authentication path is initially computed relative to the current
ladder in the MTL mode operations in this document. The target rung
for the authentication path is thus the unique rung in the ladder
that covers the data value to be authenticated. When an
authentication path is verified, however, it can be verified relative
to any of the successive ancestors of the leaf node corresponding to
the data value up to and including the target rung.
Continuing the example above, the authentication path for the data
value at index 6 can be verified relative to any ladder that includes
a rung with index 6, (6,7), (4,7) and/or (0,7). In this case, the
ladder covering the first six data values could also be used, because
it includes a rung with index 6.
More generally, if an authentication path for the data value at
leaf_index is computed relative to a ladder that covers the first N
data values, the authentication path can also be authenticated
relative to any binary rung strategy ladder that covers the first N'
data values if the following condition is met:
leaf_index <= N' <= N.
Harvey, et al. Expires 14 December 2024 [Page 22]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
The first inequality ensures that the ladder covers the data value;
the second ensures that the authentication path can reach the ladder.
This property of "backward compatibility" with previous ladders is
attractive because it provides a way for a verifier to use an old
ladder to authenticate a new authentication path, thereby potentially
reducing the number of times that the verifier needs to get a new
ladder.
To facilitate this property, the following "compatibility check" can
be applied. Let (L,R) be a rung in a ladder and let leaf_index be
the index of the data value. The rung can be used to authenticate
the data value if the following conditions hold:
* L <= leaf_index <= R, ensuring the leaf index is covered by the
rung
* (L = 0 or degree <= lsb(L)1) and RL+1 = 2^degree, where degree =
lsb(RL+1)1, ensuring the rung is indeed an apex of a perfect
binary tree in the binary rung strategy
* lsb(RL+1) is less than or equal to the number of sibling hash
values in the authentication path, ensuring the authentication
path can reach the rung
If a ladder has a rung that passes this check, then the ladder is
compatible with the authentication path. If not, then the verifier
needs to get a new ladder.
7. Data Structures
MTL mode operations use three welldefined data structures to
represent elements described in the previous section. These
structures are byte strings with number values represented in big
endian notation. The data structures provide interoperability so
that a verifier on one platform can read and verify the data provided
by a signer on another platform.
7.1. Ladder
A ladder data structure consists of four base components:
* flags, a 2byte string providing future extensibility; the initial
value for this field MUST be 0
* sid, the series identifier, a 8byte string
* rung_count, the number of rungs in the ladder, a positive integer
between 1 and 2^161
* rungs, one or more rung data structures
The rung data structure is described in the next section.
Harvey, et al. Expires 14 December 2024 [Page 23]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
The byte representation of the ladder is the concatenation of the
binary encodings of the fields using big endian representation of the
integers:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++
 Flags 
++
 
 Series Identifier (SID) 
 
 
++
 Rung Count 
++
 
// Rung Data //
 
++
7.2. Rung
A rung data structure consists of three base components:
* left_index, the left index of the rung, a nonnegative integer
* right_index, the right index of the rung, a nonnegative integer
* hash, the rung hash value, a nbyte string
The byte representation of the rung is the concatenation of the
binary encodings of the fields using big endian representation of the
integers:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++
 Left Index 
 
++
 Right Index 
 
++
 
// Rung Hash Value //
 
++
Harvey, et al. Expires 14 December 2024 [Page 24]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
7.3. Authentication Path
An authentication path data structure consists of seven base
components:
* flags, a 2byte string providing future extensibility; it MUST be
0 for this version of the document
* sid, the series identifier, a 8byte string
* leaf_index, the leaf index of the data value being authenticated,
a nonnegative integer
* sibling_hash_count, the number of sibling hash values in the
authentication path, a nonnegative integer between 0 and 2^161
* sibling_hashes, zero or more sibling hash values, each a nbyte
string
* rung_left, the left index of the target rung, a nonnegative
integer
* rung_right, the right index of the target rung, a nonnegative
integer
The byte representation of the authentication path is the
concatenation of the binary encodings of the fields using a 2byte
big endian representation for the node count and 4byte big endian
representations for the indexes:
Harvey, et al. Expires 14 December 2024 [Page 25]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++
 Flags 
++
 
 Series Identifier 
 
 
++
 Leaf Index 
 
++
 Target Rung Left Index 
 
++
 Target Rung Right Index 
 
++
 Sibling Hash Count 
++
 
// Sibling Hash Values //
 
++
8. MTL Node Set Operations
This section defines six operations supporting the use of MTL node
sets to authenticate messages.
The first four, mtl_initns, mtl_append, mtl_ladder and mtl_authpath
can be used by a signer to initialize a node set, add data values to
it, obtain the current ladder, and obtain an authentication path
relative to the current ladder. Each uses a MTL node set object to
maintain the state of the node set.
The other two, mtl_rung and mtl_verify, can be used by a verifier to
select a ladder rung that can be used to authenticate a data value
and to authenticate the data value relative to the rung.
For the MTL mode operations in this version of the document, the
following constraints apply:
* the public seed MUST be a nbyte string
* the series identifier MUST be a 8byte string
Harvey, et al. Expires 14 December 2024 [Page 26]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
* the various node indexes (leaf_index, left_index, right_index,
etc.) MUST be nonnegative integers between 0 and 2^321 (so they
can be represented as 4byte strings in big endian notation)
* the data value MUST be a nbyte string
* the various hash values (leaf_hash, left_hash, right_hash,
internal_hash, etc.) MUST be a nbyte strings
8.1. MTL Node Set Object
MTL node set objects consist of four base components: a public seed,
a series identifier, a leaf node count and a dynamic array of node
hash values.
Consistent with the definition of a node set in Section 6.2, the
array is indexed by two values. The hash value for the leaf node
with index leaf_index is stored at hashes[leaf_index, leaf_index] and
the hash value for the internal node with index pair (left_index,
right_index) is stored at hashes[left_index, right_index]. The
organization of the array is up to the implementation.
A new MTLNS node set object initially has a specified public seed and
series identifier, a node count of 0 and an empty array of hash
values.
8.2. MTL Node Set Hash Operations
As discussed in Section 6.3 and Section 6.4, MTL mode node sets are
constructed using two hash operations hash_leaf and hash_int. The
hash operations are specified in terms of the SPHINCS+ abstract
cryptographic functions and the address scheme in Section 4.
8.2.1. Hashing a Data Value to Produce a Leaf Node Hash Value
(Function: hash_leaf)
hash_leaf is a supporting function that hashes a data value to
produce a leaf node. The operation takes a public seed, a series
identifier, a leaf index and a data value as input and returns a leaf
node hash value.
The operation uses the MTL_DATA address type and the abstract
cryptographic function F.
Harvey, et al. Expires 14 December 2024 [Page 27]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
##################################################################
# Algorithm 1: Hashing a Data Value to Produce a Leaf Node.
##################################################################
# Input: seed, public seed for the node set (associated with
# public key)
# Input: sid, series identifier for the node set
# Input: leaf_index of the leaf node hash value
# being computed
# Input: data_value corresponding to the leaf node
# Output: leaf_hash, leaf node hash value
def hash_leaf(seed, sid, leaf_index, data_value):
dataADRS = spx.ADRS()
dataADRS.setType(spx.ADRS.MTL_DATA)
dataADRS.setSID(sid)
dataADRS.setLeafIndex(leaf_index)
leaf_hash = spx.F(seed, dataADRS.bytes(), data_value)
return leaf_hash
8.2.2. Hashing Two Child Nodes to Produce an Internal Node
hash_int is a supporting function that hashes two child nodes to
produce an internal node. The operation takes a public seed, a
series identifier, a left index, a right index, a left child hash
value and a right child hash value as input and returns an internal
node hash value.
The operation uses the MTL_TREE address type and the abstract
cryptographic function H.
Harvey, et al. Expires 14 December 2024 [Page 28]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
##################################################################
# Algorithm 2: Hashing Two Child Nodes to Produce an Internal Node.
##################################################################
# Input: seed, public seed for the node set (associated with
# public key)
# Input: sid, series identifier for the node set
# Input: left_index, left index of the internal node
# Input: right_index, right index of the internal node
# Input: left_hash, left child hash value
# Input: right_hash, right child hash value
# Output: internal_hash, internal node hash value
def hash_int(seed, sid, left_index, right_index, left_hash,
right_hash):
mtlnsADRS = spx.ADRS()
mtlnsADRS.setType(spx.ADRS.MTL_TREE)
mtlnsADRS.setSID(sid)
mtlnsADRS.setLeftRightIndexes(left_index, right_index)
internal_hash = spx.H(seed, mtlnsADRS.bytes(), left_hash,
right_hash)
return internal_hash
8.3. Initializing a MTL Node Set (Function: mtl_initns)
mtl_initns initializes a new MTL node set. The operation takes a
public seed and a series identifier as input and returns a new MTL
node set object.
##################################################################
# Algorithm 3: Initializing a MTL Node Set.
##################################################################
# Input: seed, public seed for the node set (associated with
# public key)
# Input: sid, series identifier for the node set
# Output: node_set, new MTL node set object
def mtl_initns(seed, sid):
node_set = MTLNS(seed, sid)
return node_set
Harvey, et al. Expires 14 December 2024 [Page 29]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
8.4. Appending a Data Value to a MTL Node Set (Function: mtl_append)
mtl_append appends a data value to a MTL node set, adding a leaf node
and internal nodes as needed to produce a new ladder covering the
expanded series of data values. The operation takes a data value and
a MTL node set object as input and returns the new leaf index. The
MTL node set object is updated in place.
mtl_append maintains the node set in a way that can produce ladders
and authentication paths with the binary rung strategy.
The operation has two primary steps. First, a new leaf node is
computed from the data value and added to the node set. Second, new
internal nodes are computed from other nodes (if needed) and added to
the node set to produce a new ladder covering the expanded series of
data values.
##################################################################
# Algorithm 4: Appending a Data Value to a MTL Node Set.
##################################################################
# Input: data_value to append to the node set
# Input: node_set, MTL node set object (updated in place)
# Output: leaf_index assigned to the data value
def mtl_append(data_value, node_set):
leaf_index = node_set.count
node_set.count = leaf_index + 1
seed = node_set.seed
sid = node_set.sid
# Compute and store the leaf node hash value
node_set.hashes[leaf_index,leaf_index] = hash_leaf(seed, sid,
leaf_index, data_value)
# Compute and store additional internal node hash values
for i in range(1,lsb(leaf_index+1)):
left_index = leaf_index  2**i + 1
mid_index = leaf_index  2**(i1) + 1
node_set.hashes[left_index, leaf_index] = hash_int(seed,
sid, left_index, leaf_index,
node_set.hashes[left_index, mid_index  1],
node_set.hashes[mid_index, leaf_index])
return leaf_index
Harvey, et al. Expires 14 December 2024 [Page 30]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
8.5. Computing an Authentication Path (Function: mtl_authpath)
mtl_authpath computes an authentication path for the data value at a
specified leaf index relative to the current ladder for a MTL node
set. The operation takes a leaf index and a node set object as input
and returns an authentication path from the leaf node to its
associated rung in the node set's current ladder.
mtl_authpath produces the authentication path with the binary rung
strategy.
The operation has two primary steps. First, the current ladder rung
covering the specified leaf index is selected. Second, the sibling
hash values from the leaf node to the rung are concatenated to
produce the authentication path.
Harvey, et al. Expires 14 December 2024 [Page 31]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
##################################################################
# Algorithm 5: Computing an Authentication Path for a Data Value.
##################################################################
# Input: leaf_index, leaf node index of the data value to
# authenticate
# Input: node_set, MTL node set object encompassing the specified
# leaf node
# Output: auth_path, authentication path from the leaf node to
# the associated rung
def mtl_authpath(leaf_index, node_set):
left_index = 0
sibling_hashes = []
flags = 0
# Check that the leaf is part of this node set
if(leaf_index < 0) or (leaf_index >= node_set.count):
return None # Leaf is outside of node set
# Find the rung index pair covering the leaf index
for i in range(msb(node_set.count),1,1):
if node_set.count & (1 << i):
right_index = left_index + 2**i  1
if leaf_index <= right_index:
break
left_index = right_index + 1
# Concatenate the sibling nodes from the leaf to the rung
for i in range(0, bit_width(right_indexleft_index)):
if leaf_index & (1<= leaf_index)):
degree = lsb(right_indexleft_index+1)1
if(((degree <= lsb(left_index)1) or
(lsb(left_index) == 0)) and
(right_indexleft_index+1 == 2**degree) and
(degree <= sibling_hash_count)):
if((assoc_rung == None) or
(degree < min_degree)):
assoc_rung = rung
min_degree = degree
return assoc_rung
8.8. Verifying an Authentication Path (Function: mtl_verify)
mtl_verify verifies an authentication path for a data value relative
to a rung. It takes a public seed, a data value and a rung as input
and returns a Boolean value indicating whether the data value is
successfully authenticated.
Harvey, et al. Expires 14 December 2024 [Page 34]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
mtl_verify supports authentication paths produced with the binary
rung strategy.
The operation has two primary steps. First, a leaf node hash value
is computed from the data value using hash_leaf. If the leaf node
index matches the rung index pair, the leaf node hash value is
compared to the rung hash value. Second, internal node hash values
are computed as needed from the leaf node hash value and successive
sibling hash values in the authentication path using hash_int. Along
the way, if the internal node index pair matches the rung index pair,
then the internal hash value is compared to the rung hash value.
##################################################################
# Algorithm 8: Verifying an Authentication Path.
##################################################################
# Input: seed value for this operation (associated with public key)
# Input: data_value to authenticate
# Input: auth_path, (presumed) authentication path from corresponding
# leaf node to rung of ladder covering leaf node
# Input: assoc_rung, Merkle tree rung to authenticate relative to
# Output: result, a Boolean indicating whether the data value is
# successfully authenticated
def mtl_verify(seed, data_value, auth_path, assoc_rung):
sid = auth_path.sid
leaf_index = auth_path.leaf_index
sibling_hash_count = auth_path.sibling_hash_count
# Recompute leaf node hash value
target_hash = hash_leaf(seed, sid, leaf_index, data_value)
# Compare leaf node hash value to associated rung hash value if
# index pairs match
if ((leaf_index == assoc_rung.left_index) and
(leaf_index == assoc_rung.right_index)):
return target_hash == assoc_rung.hash
# Recompute internal node hash values and compare to
# associated rung hash value if index pairs match
for i in range(1, sibling_hash_count+1):
left_index = leaf_index & ~(2**i1)
right_index = left_index + 2**i 1
mid_index = left_index + 2**(i1)
sibling_hash = auth_path.sibling_hash[i1]
if leaf_index < mid_index:
target_hash = hash_int(seed, sid, left_index,
Harvey, et al. Expires 14 December 2024 [Page 35]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
right_index, target_hash,
sibling_hash)
else:
target_hash = hash_int(seed, sid, left_index,
right_index, sibling_hash,
target_hash)
# Break if associated rung reached
if((left_index == assoc_rung.left_index) and
(right_index == assoc_rung.right_index)):
return target_hash == assoc_rung.hash
return False
9. Signing and Verifying Messages in MTL Mode
Descriptions of the signer's and the verifier's operations in a
typical application based on MTL mode are given in Section 9.1 and
Section 9.2. Section 9.3 discusses how to identify ladders to
facilitate interoperability. Representations of full and condensed
MTL mode signatures are given in Section 9.4 and Section 9.5.
9.1. Signing Messages
A signer MUST perform the following or an equivalent set of
operations to sign messages in MTL mode.
The first step is performed once per key pair:
1. Generate a public / private key pair for an underlying signature
scheme, where the public key includes a public seed and a public
root and the private key includes a public seed, a public root,
and a secret PRF key.
The second step is performed once per series of messages to be
signed:
2. Initialize a node set for the series from a public seed and a
series identifier using mtl_initns. The message index for the
message series is set to 0 in this step.
The third and fourth steps are performed once per message to be
signed in a message series:
Harvey, et al. Expires 14 December 2024 [Page 36]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
3. Compute a randomizer and a data value from the message, the
context string, the series identifier and the message index for
the message series as described in Section 5.1. Note that a
domain separator of type MTL_MSG_SEP is prepended to the inputs
to functions in Section 5.1. (See Section 4.7 for further
discussion.)
4. Append the data value to the node set for the message series
using mtl_append. The message index for the message series is
incremented in this step.
The fifth and sixth steps are performed whenever the signer wants to
produce a new signed ladder for the message series. The signer could
do so after each new message is added, or after a new batch of new
messages is added.
5. Compute the current ladder for the node set using mtl_ladder.
6. Format a domain separator sep from the context string as follows:
sep = octet(MTL_LADDER_SEP)  octet(OLEN(ctx))  ctx  OID_MTL
Sign the ladder prepended with the domain separator using the private
key of the underlying signature scheme. (See Section 4.7 for further
discussion).
The seventh step is performed whenever the signer wants to provide a
signed ladder to a requester, e.g., upon request by a verifier.
(This step may not be needed if the signer supports the alternative
of providing a full signature including the authentication path and a
ladder.)
7. Provide the signed ladder associated with a specified ladder
identifier.
The eighth step is performed whenever the signer wants to compute a
new authentication path for a message relative to the current ladder
for the message series. The signer could do so after each new
message is added, after a batch of new messages is added, and/or
later, as needed, to update the authentication paths for older
messages so that they are relative to the current ladder.
8. Compute an authentication path for the data value at a specified
message index relative to the current ladder using mtl_authpath.
The ninth step is performed whenever the signer wants to provide
authentication information to a requester, e.g., in conjunction with
a message to be authenticated.
Harvey, et al. Expires 14 December 2024 [Page 37]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
9. Provide the authentication path and the randomizer associated
with a message to be authenticated, e.g., in a condensed
signature. The signer MAY also provide an explicit ladder
identifier for the ladder that the authentication path was
computed relative to  see Section 9.3. Alternatively, the
signer may offer the option of requesting a full signature that
includes the authentication path, the randomizer and a signed
ladder.
9.2. Verifying Signatures
A verifier MUST perform the following or an equivalent set of
operations to verify signatures in MTL mode:
The first step is performed once per key pair by each verifier:
1. Obtain the signer's public key for the underlying signature
scheme, where the public key includes a public seed and a public
root.
The second, third, fourth and fifth steps is performed as needed for
each message to be authenticated:
2. Obtain the authentication path and the randomizer associated with
the message to be authenticated, e.g., in a condensed signature.
The verifier MAY also obtain an explicit ladder identifier for
the ladder that the authentication path was computed relative to
 see Section 9.3.
3. Determine whether any of ladders held by the verifier includes a
rung compatible with the authentication path, e.g., using
mtl_rung. If not, then proceed to Step 6 and return here.
4. Recompute a data value from the message, the context string, the
series identifier in the authentication path and the message
index in the authentication path and the randomizer as described
in Section 5.2. Note that a domain separator of type MTL_MSG_SEP
is prepended to the message prior to calling the functions in
Section 5.2. (See Section 4.7 for further discussion).
5. Verify the authentication path for the data value at a specified
message index relative to the compatible rung using mtl_verify.
The sixth and seventh steps are performed when the verifier doesn't
have a ladder compatible with an authentication path.
Harvey, et al. Expires 14 December 2024 [Page 38]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
6. Obtain the signed ladder associated with a specified ladder
identifier. Alternatively, the verifier may request a full
signature including an authentication path and the signed ladder
that it is computed relative to.
7. Format a domain separator sep from the context string and the MTL
mode object identifier as follows:
sep = octet(MTL_LADDER_SEP)  octet(OLEN(ctx))  ctx  OID_MTL
Verify the signature on the ladder prepended with the domain
separator using the public key of the underlying signature scheme.
(See Section 4.7 for further discussion).
9.3. Ladder identifiers
To facilitate interoperability, an application SHOULD have a way for
signers and verifiers to identify a specific signed ladder that a
verifier is interested in obtaining.
Potential approaches include:
* Identifying the ladder based on a public key identifier and
information in the authentication path itself, i.e., the series
identifier and the target index pair. This combination is
sufficient to identify the public key, the series of data values
(and thus the MTL node set), and the ladder of interest (given the
target index pair, with the binary rung strategy).
* Identifying the ladder with a URI or other explicit identifier
that refers to a location where the signed ladder is stored or to
the signed ladder itself. This URI can be conveyed together with
the authentication path in an application.
* Specifying interest in a ladder implicitly by setting a flag in
the request for a message and its associated authentication path.
When the flag is not set, the message and authentication path
would be returned (producing a condensed signature  see
Section 9.5). When the flag is set, the message, the signed
ladder is also would be returned (producing a full signature  see
Section 9.4).
The approach MAY be protocolspecific, e.g., the approach used for
identifying MTL mode ladders associated with DNSSEC signatures MAY be
different than the one used for MTL mode ladders associated with
certificates.
Harvey, et al. Expires 14 December 2024 [Page 39]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
9.4. Full Signatures
An application MAY convey a "full" signature  including a
randomizer, an authentication path, a ladder and its signature  with
the following data structure. A full signature is convenient as a
"dropin" for a conventional signature because it can be verified on
its own. However, it includes the overhead of the underlying
signature on the ladder.
A full MTL mode signature data structure consists of five base
components:
* R_mtl, the randomizer, a nbyte string
* auth_path, the authentication path Section 7.3
* ladder, the ladder Section 7.1
* sig_len, the length in bytes of the underlying signature on the
ladder, a positive integer between 1 and 2^321 (so it can be
represented as 4byte string in big endian notation)
* sig, the underlying signature on the ladder, a schemespecific
string
The byte representation of the full MTL mode signature is the
concatenation of the binary encodings of the fields, using a 4byte
big endian representation for the signature length.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++
 
// Randomizer //
 
++
 
// Authentication Path //
 
++
 
// Ladder //
 
++
 Underlying Signature Length 
 
++
 
// Underlying Signature //
 
++
Harvey, et al. Expires 14 December 2024 [Page 40]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
Note that the last three components are the same as a signed ladder
(Section 9.6).
9.5. Condensed Signatures
An application MAY convey a "condensed" signature  including a
randomizer and an authentication path but not a ladder and its
signature  with the following data structure. A condensed signature
is convenient for reducing the size impact of the ladder signature.
However, it requires the verifier to obtain the ladder from a
separate source.
A condensed MTL mode signature data structure consists of two base
components:
* R_mtl, the randomizer, a nbyte string
* auth_path, the authentication path (Section 7.3)
The byte representation of the condensed MTL mode signature is the
concatenation of the binary encodings of the fields.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++
 
// Randomizer //
 
++
 
// Authentication Path //
 
++
9.6. Signed Ladders
A signed ladder data structure consists of three base components:
* ladder, the ladder (Section 7.1)
* sig_len, the length in bytes of the underlying signature on the
ladder, a positive integer between 1 and 2^321 (so it can be
represented as 4byte string in big endian notation)
* sig, the underlying signature on the ladder, a schemespecific
string
The byte representation of the signed ladder is the concatenation of
the binary encodings of the fields, using a 4byte big endian
representation for the signature length.
Harvey, et al. Expires 14 December 2024 [Page 41]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++
 
// Ladder //
 
++
 Underlying Signature Length 
 
++
 
// Underlying Signature //
 
++
10. SPHINCS+ in MTL Mode
SPHINCS+MTL applies MTL mode to the underlying signature scheme
SPHINCS+. This document supports 24 instantiations corresponding to
the 12 instantiations in the SPHINCS+ specification based on the
SHAKE hash function [FIPS202] and the 12 instantiations based on the
SHA2 hash functions [FIPS1804]. (In contrast to SPHINCS+, this
document does not support instantiations based on the Haraka hash
function [HARAKA]  see Note.) This draft also supports the subset
of instantiations for SLHDSA as defined in the draft [FIPS205IPD].
Note: As FIPS 205 evolves the changes will be tracked and updates may
be made to this document as is appropriate.
The names of the SPHINCS+MTL instantiations follow a similar
convention to the SPHINCS+ instantiations:
* SPHINCS+MTL{hash}{bitsec}{opt}{variant}
The components of the name are as follows:
* {hash} is the underlying hash function. For this version of the
document, it MUST be "SHAKE" or "SHA2", corresponding to the
underlying hash function.
* {bitsec} is the target bit security. It MUST be "128", "192" or
"256", corresponding to the "bitsec" value in [SPHINCSPLUS]. The
security parameter n is the target bit security level divided by
8, i.e., 16, 24 or 32. The corresponding NIST security levels for
these bit security levels are 1, 3 and 5.
Harvey, et al. Expires 14 December 2024 [Page 42]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
* {opt} is the optimization goal. It MUST be "s" or "f". As
discussed in [SPHINCSPLUS], the "s" optimization results in
smaller signature sizes, while the "f" optimization results in
faster signing operations.
* {variant} is the style of the tweakable hash function. It must be
"simple" or "robust". As discussed in [SPHINCSPLUS], the
"simple" style results in faster operations, while the "robust"
style results in more conservative security proofs.
SPHINCS+MTL with a given set of components is based on the
underlying signature scheme SPHINCS+ with the same components.
SPHINCS+MTL{hash}{bitsec}{opt}{variant} may thus be read as "MTL
mode of SPHINCS+{hash}{bitsec}{opt}{variant}".
The four components may be chosen independently of one another.
Given that there are two choices of {hash}, three choices of
{bitsec}, two choices of {opt}, and two choices of {variant}, the
total number of instantiations is 2*3*2*2 = 24. The table below
lists the names of the 24 supported instantiations, their associated
security parameter n, and their NIST security levels.
As in SPHINCS+ itself, the instantiations of the abstract
cryptographic functions in the MTL mode operations depend on the
underlying hash function and the security parameter. The function
definitions for each instantiation are given in the following
subsections. With the exception of H_msg_mtl, which is new, the
instantiations of the functions are the same as in SPHINCS+ and are
repeated here for completeness. Recall that the parameters to these
functions should be provided as defined in Section 5 of this draft.
NOTE: This document does not include Haraka because it is not a NIST
approved hash function and because SPHINCS+ with Haraka only achieves
NIST security levels 1 and 2.
Harvey, et al. Expires 14 December 2024 [Page 43]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
SPHINCS+MTL Security NIST
Instantiation Parameter n Level
+++
 SPHINCS+MTLSHAKE128ssimple  16  1 
 SLHDSAMTLSHAKE128s   
+++
 SPHINCS+MTLSHAKE128fsimple  16  1 
 SLHDSAMTLSHAKE128f   
+++
 SPHINCS+MTLSHAKE192ssimple  24  3 
 SLHDSAMTLSHAKE192s   
+++
 SPHINCS+MTLSHAKE192fsimple  24  3 
 SLHDSAMTLSHAKE192f   
+++
 SPHINCS+MTLSHAKE256ssimple  32  5 
 SLHDSAMTLSHAKE256s   
+++
 SPHINCS+MTLSHAKE256fsimple  32  5 
 SLHDSAMTLSHAKE256f   
+++
 SPHINCS+MTLSHA2128ssimple  16  1 
 SLHDSAMTLSHA2128s   
+++
 SPHINCS+MTLSHA2128fsimple  16  1 
 SLHDSAMTLSHA2128f   
+++
 SPHINCS+MTLSHA2192ssimple  24  3 
 SLHDSAMTLSHA2192s   
+++
 SPHINCS+MTLSHA2192fsimple  24  3 
 SLHDSAMTLSHA2192f   
+++
 SPHINCS+MTLSHA2256ssimple  32  5 
 SLHDSAMTLSHA2256s   
+++
 SPHINCS+MTLSHA2256fsimple  32  5 
 SLHDSAMTLSHA2256f   
+++
10.1. SHAKE instantiations
The SHAKE instantiations employ the SHAKE256 hash function [FIPS202].
Harvey, et al. Expires 14 December 2024 [Page 44]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
10.1.1. Randomized message digest function (H_msg_mtl)
The randomized message digest function H_msg_mtl (see Section 4.3) is
defined the same as the function H_msg in SPHINCS+ except that
H_msg_mtl's output is 8n bits (n bytes) rather than 8m bits (m
bytes):
H_msg_mtl(R, PK.seed, PK.root, M) = SHAKE256(R  PK.seed 
PK.root  M, 8n)
10.1.2. Pseudorandom function (PRF_msg)
The pseudorandom function PRF_msg (see Section 4.4) is defined the
same as in SPHINCS+:
PRF_msg(SK.prf, OptRand, M) = SHAKE256(SK.prf  OptRand  M, 8n)
10.1.3. Tweakable hash functions (F and H)
The tweakable hash functions F and H (see Section 4.5) are defined
the same as in SPHINCS+. In the robust variants, they are defined as:
F(PK.seed, ADRS, M_1) = SHAKE256(PK.seed  ADRS  M_1*, 8n)
H(PK.seed, ADRS, M_1, M_2) = SHAKE256(PK.seed  ADRS 
(M_1 M_2)*, 8n)
with the following notation:
M_1* = M_1 xor SHAKE256(PK.seed, ADRS, 8n)
(M_1  M_2)* = (M_1  M_2)* xor SHAKE256(PK.seed, ADRS, 16n)
In the simple variants, they are defined as:
F(PK.seed, ADRS, M_1) = SHAKE256(PK.seedADRSM_1, 8n)
H(PK.seed, ADRS, M_1, M_2) = SHAKE256(PK.seed  ADRS  M_1 
M_2, 8n)
NOTE: The definition of H in the robust variant above corrects a typo
in the SPHINCS+ specification. In SPHINCS+, the string input to
SHAKE256 (in the notation of this document) is PK.seed  ADRS 
M_1*  M_2_. Following that specification, both M_1 and M_2 would be
xored with the same mask value, SHAKE256(PK.seed, ADRS, 8n). The
intent in SPHINCS+ is rather that the concatenation (M_1  M_2) is
xored with a longer mask, as is also done in the SHA2 instantiations.
This document therefore replaces M_1_  M_2* with (M_1  M_2)*.
Harvey, et al. Expires 14 December 2024 [Page 45]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
10.2. SHA2 instantiations
The SHA2 instantiations employ the SHA2256 and/or SHA2512 hash
functions [FIPS1864], the HMACSHA2256 and/or HMACSHA2512 message
authentication codes (pseudorandom functions) [FIPS1981] and the
MGF1SHA2256 and/or MGF1SHA2512 mask generation functions
[RFC8017]. (Here and in the following, SHAX denotes SHA2256 when n
= 16 and SHA2512 when n = 24 or 32.)
10.2.1. Randomized message digest function (H_msg_mtl)
The randomized message digest function H_msg_mtl (see Section 4.3) is
defined the same as the function H_msg in SPHINCS+ except that its
output is n bytes rather than m bytes:
H_msg_mtl(R, PK.seed, PK.root, M) = MGF1SHAX(R  PK.seed 
SHAX(R  PK.seed  PK.root  M), n).
10.2.2. Pseudorandom function (PRF_msg)
The pseudorandom function PRF_msg (see Section 4.4) is defined the
same as in SPHINCS+:
PRF_msg(SK.prf, OptRand, M) = HMACSHAX(SK.prf, OptRand  M)
10.2.3. Tweakable hash functions (F and H)
The tweakable hash functions F and H (see Section 4.5) are defined
the same as in SPHINCS+. In the robust variants, they are defined as:
F(PK.seed, ADRS, M_1) = SHA2256(BlockPad(PK.seed)  ADRS^c 
M_1*)
H(PK.seed, ADRS, M_1, M_2) = SHAX(BlockPad(PK.seed)  ADRS^c 
(M_1 M_2)*)
with the following notation:
BlockPad(PK.seed) = PK.seed  toByte(0, bln) where bl=64 for
SHA2256 and bl=128 for SHA512.
ADRS^c is a 22byte "compressed" version of the address value that
omits bytes 13, 58 and 2123. (In MTL mode, the omitted bytes
are all zeros because the address type is one byte long  see
Section 3.4.)
M_1* = M_1 xor MGF1SHAX(PK.seed, ADRS, 8n)
Harvey, et al. Expires 14 December 2024 [Page 46]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
(M_1  M_2)* = (M_1  M_2)* xor MGF1SHAX(PK.seed, ADRS, 16n)
In the simple variants, they are defined as:
F(PK.seed, ADRS, M_1) = SHA2256(BlockPad(PK.seed)  ADRS^c 
M_1)
H(PK.seed, ADRS, M_1, M_2) = SHAX(BlockPad(PK.seed)  ADRS^c 
(M_1 M_2))
11. Calculating Maximum Signature Sizes
Parameters required for calculation:
* n = Security parameter for the underlying signature scheme
(Section 10)
* USS = Size of underlying signature (Table 1 SLHDSA parameter sets
in [FIPS205IPD])
* N = Number of messages in message series
Calculations:
Max Condensed Signature Size = n + 24 + (n * floor(log2N))
(Section 6.6, Section 7.3, Section 9.5)
Max Signed Ladder Size = 16 + ((8 + n) * ceiling(log2(N))) + USS
(Section 6.5, Section 7.1, Section 9.6)
Max Full Signature Size = Max Condensed Signature Size + Max
Signed Ladder Size (Section 9.4)
12. Related Work
The binary rung strategy appears under different names in other
cryptographic constructions based on Merkle trees. Champine defines
a binary numeral tree [BINNUMTREES] with similar structure (the
successive perfect binary subtrees are called eigentrees). Other
similarMerkle treebased constructions include Crosby and Wallach's
history trees [HISTORYTREE], Todd's Merkle mountain ranges
[MERKLE_MOUNTAIN], and Reyzin and Yakoubov's cryptographic
accumulator [CRYPTOACC], which achieves an "oldaccumulator
compatibility" property comparable to the backward compatibility
property described here for the binary rung strategy. Certificate
transparency logs take advantage of Merkle trees to show the
existence or nonexistence of a certificate as published by a
certification authority [RFC9162]. Benjamin, O'Brien, and Westerbaan
[MERKLETREECERTS] propose using authentication paths to a limited
lifetime Merkle tree produced by a certificate transparency service
as certificate signatures. Each Merkle tree is constructed over a
fixed time window in this approach, and the authentication paths are
Harvey, et al. Expires 14 December 2024 [Page 47]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
constructed relative to the single root of the Merkle tree, which is
like a singlerung Merkle tree ladder.
13. IANA Considerations
This document makes no requests of IANA. However, a future version
of this document may request that IANA register any or all of the
following:
* flag values for the ladder and authentication path data
structures;
* object identifiers for the various instantiations of MTL mode
combined with underlying signature schemes;
* the domain separator types MTL_MSG_SEP and possibly
MTL_LADDER_SEP; and
* the address types MTL_MSG, MTL_DATA, and MTL_TREE.
Because the domain separator types build on NIST's proposed domain
separation scheme, the request for domain separator types may depend
on the existence of a registry for domain separation type.
Similarly, because the address types build on the SPHINCS+ address
scheme, that request may depend on the existence of a registry for
SPHINCS+ address types in conjunction with the standardization of
SPHINCS+ by the IETF.
14. Security Considerations
Implementers MUST use a secure random generator [RFC4086].
Implementers MUST select a security parameter consistent with their
security requirements.
Implementers MUST also select cryptographic functions that are
generally accepted for their intended security level and use within
MTL mode. Similar to SPHINCS+, the desired properties for the
cryptographic functions in MTL mode are that PRF_msg is a
pseudorandom function and F and H are multitarget, multifunction
second preimage resistant function families. The desired property
for H_msg_mtl is that it is an extended target collision resistant
function with nonce (where the nonce is provided as the message index
in the prepended address value).
Because MTL mode is an addon to an underlying signature scheme,
implementers MUST ensure adequate cryptographic separation between
MTL mode's uses of cryptographic functions and the use of
cryptographic functions by the underlying signature scheme. The
operations in Section 5.1, Section 5.2, Section 9.1, and Section 9.2
including the domain separators, and the proposed instantiations in
Harvey, et al. Expires 14 December 2024 [Page 48]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
Section 10 were selected taking cryptographic separation between MTL
mode and SPHINCS+ into account. Other underlying signature schemes
need to be evaluated separately.
To avoid unintended interactions between the different instantiations
of MTL mode, a given key pair SHOULD only be used with a single
instantiation of MTL mode.
The signer in MTL mode maintains a Merkle tree node set and is
therefore stateful. Implementers SHOULD ensure that the node set is
maintained accurately and is not at risk of being reset or repeated,
or otherwise the security of MTL mode could be degraded. In
particular, as discussed in [MTLMODE], the reuse of state in MTL
mode could provide additional target hash values for an adversary to
match in an attack on the hash function, thereby weakening the
provable security bounds. In contrast to hashbased signature
schemes, however, the reuse of state in MTL mode does not reveal
information about a private key that could directly lead to a
signature forgery.
Similar to SPHINCS+, the security of MTL mode relies on a form of
target collision resistance. Target collision resistance assumes
that the message is hashed together with a randomizer that is
produced with a secure random generator. An advantage of target
collision resistance over basic collision resistance (without a
randomizer) is that the bit security level associated with security
parameter n can be achieved with an nbyte hash value rather than a
2nbyte hash value. This advantage reduces the size of the
authentication paths and ladders in MTL mode, in a similar way that
it reduces the size of the signatures in SPHINCS+. If the randomizer
in the MTL mode operations is not produced securely, however, then
the security of the MTL mode operations could be significantly at
risk. In particular, if an adversary can predict the randomizer,
then an attacker can potentially perform a basic collision attack to
find two messages that hash to the same hash value together with the
predicted randomizer. Because the hash value is only n bytes, the
implementation in this case would only have roughly 4n bits of
security rather than the target 8n bits.
Section 5.1 suggests one primary approach to secure random
generation, namely the use of a pseudorandom function PRF_msg. This
is the same approach that SPHINCS+ takes, but the inputs are
different for the MTL mode operations.
In SPHINCS+, the PRF is applied to an optional external random value
and the message being signed. Including the message ensures that the
randomizer for one signature operation is cryptographically
independent from the randomizer for another signature operation
Harvey, et al. Expires 14 December 2024 [Page 49]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
involving a different message, while maintaining the statelessness of
SPHINCS+. If same message is signed twice, however, the same
randomizer and ultimately the same signature will be generated
(deterministic signing). Deterministic signing could increase the
risk of sidechannel attacks revealing information about the signer's
private key if the same computation is run multiple times. Including
the optional random value avoids deterministic signing and mitigates
this particular risk.
In the MTL mode operations, following the suggested example in
Section 5.1, the PRF is applied to an optional external random value
and an address value. Including the address value ensures that the
randomizer for one signature operation is cryptographically
independent from another signature operation, regardless of the
message being signed. Here, the MTL mode operations are already
stateful, and implementations are assumed to be able to maintain a
unique address value. If the implementation is not able to maintain
a unique address value, however, and uses the same address value more
than once, the same randomizer will be generated when the address
value is used again, making it predictable. This could lead to a
basic collision attack. Including the optional random value avoids
this predictability and mitigates the risk. Section 5.1 also
suggests the option of including the message in the input in addition
to the address value, which is another way to avoid the
predictability of the randomizer if the same address value is used
more than once (with a different message each time). As noted in
Section 5.1, however, including the message involves an additional
pass over the message (once for PRF_msg and once for H_msg_mtl),
which can be disadvantageous if the message is long. For this
reason, including the message is OPTIONAL.
This specification uses a domain separator format to distinguish
between the use of an underlying signature scheme in MTL mode from
its use in pure and prehash modes. The domain separator format is
beneficial in an application that potentially supports MTL mode in
addition to pure or more modes of operation for a given key pair.
Other ways to protect against unintended interactions between the use
of a key pair in different modes of operation include (a) supporting
only a single mode of operation within the application, e.g., only
MTL mode, and not allowing key pairs used within the application to
be used in other applications; and (b) specifying the mode of
operation for a key pair as part of key management information (e.g.,
via an algorithm identifier or key usage constraints).
Considerations for the optional context string are intended to be the
same as those for the underlying signature scheme (if it supports
one, as FIPS 204 and FIPS 205 are intended to). Section 8.3 of
[RFC8032] provides helpful guidance on the use of context strings.)
Harvey, et al. Expires 14 December 2024 [Page 50]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
An adversary who learns a set of messages and their MTL mode
signatures also learns the leaf nodes of the Merkle node set
corresponding to these messages, the authentication paths in the
signatures, and the signed ladders in the signatures. Such an
adversary can also compute any nodes of the Merkle node set that
depends on the nodes it has learned, and form other condensed and
full signatures on the messages it has learned (see Section E.2.4 for
discussion; the adversary can perform the same steps as an
intermediary). Even with the ability to reconstruct the Merkle node
set, however, assuming cryptographic security of MTL mode and the
underlying signature scheme, an adversary cannot form signatures on
messages that have not already been signed by the signer, as it does
not have access to the signer's private key.
The adversary also cannot form signatures on messages that have
already been signed by the signer but that the adversary has not yet
learned, because the adversary does not know and cannot predict the
randomizers associated with those messages. Moreover, because of the
lack of knowledge about the other messages' randomizers, the
adversary also cannot determine which messages have been signed based
on the reconstructed Merkle node set, other than those whose
randomizers it has already learned. Therefore, even though the
Merkle tree node set can gradually be reconstructed publicly, the
individual messages that have been signed by the signer remain
private until the signer publishes them.
15. References
15.1. Normative References
[FIPS1804]
National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", National Institute of
Standards and Technology", FIPS PUB 1804,
DOI 10.6028/NIST.FIPS.1804, August 2015,
.
[FIPS1864]
National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS PUB 1864,
DOI 10.6028/NIST.FIPS.1864, July 2013,
.
[FIPS1981]
National Institute of Standards and Technology (NIST),
"The KeyedHash Message Authentication Code (HMAC)", FIPS
Harvey, et al. Expires 14 December 2024 [Page 51]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
PUB 1981, DOI 10.6028/NIST.FIPS.1981, July 2008,
.
[FIPS202] National Institute of Standards and Technology (NIST),
"SHA3 Standard: PermutationBased Hash and Extendable
Output Functions", FIPS PUB 202,
DOI 10.6028/NIST.FIPS.202, August 2015,
.
[FIPS204IPD]
National Institute of Standards and Technology (NIST),
"ModuleLatticeBased Digital Signature Standard", FIPS
PUB 204 (Initial Public Draft), DOI 10.6028/NIST.FIPS.204,
24 August 2023,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
15.2. Informative References
[BINNUMTREES]
Champine, L., "Streaming Merkle Proofs within Binary
Numeral Trees", Cryptology ePrint Archive Paper 2021/038,
2021, .
Harvey, et al. Expires 14 December 2024 [Page 52]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
[CRYPTOACC]
Reyzin, L. and S. Yakoubov, "Efficient data structures for
tamperevident logging", Zikas, V., De Prisco, R. (eds)
Security and Cryptography for Networks SCN 2016, LNCS,
vol. 9841, pp. 292309. Springer, Cham, 2016,
.
[FIPS205IPD]
National Institute of Standards and Technology (NIST),
"Stateless HashBased Digital Signature Standard", FIPS
PUB 205 (Initial Public Draft), DOI 10.6028/NIST.FIPS.205,
24 August 2023,
.
[HARAKA] Kolbl, S., Lauridsen, L., Mendel, F., and C. Rechberger,
"Haraka v2  Efficient ShortInput Hashing for Post
Quantum Applications", in IACR Transactions on Symmetric
Cryptology volume 2016, number 2, pages 129,
DOI 10.13154/tosc.v2016.i2.129, 2017,
.
[HISTORYTREE]
Crosby, S. and D. Wallach, "Efficient data structures for
tamperevident logging", Proceedings of the 18th USENIX
Security Symposium pp. 317334. USENIX Association (2009),
.
[MERKLETREECERTS]
Benjamin, D., O'Brien, D., and B. Westerbaan, "Merkle Tree
Certificates for TLS", Work in Progress, InternetDraft
draftdavidbentlsmerkletreecerts00, 10 March 2023,
.
[MERKLE_MOUNTAIN]
Todd, P., "Merkle Mountain Ranges",
.
[MTLMODE] Fregly, A., Harvey, J., Kaliski, B., and S. Sheth, "Merkle
Tree Ladder Mode: Reducing the Size Impact of NIST PQC
Signature Algorithms in Practice", in Rosulek, M.
(editor), Lecture Notes in Computer Science VOLUME 13871,
CTRSA 2023  Cryptographers Track at the RSA
Conference pages 415441,
DOI 10.1007/9783031308727_16, 2023,
.
Harvey, et al. Expires 14 December 2024 [Page 53]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
[NISTPREHASHUPDATE]
Moody, D., "Updates on prehash for FIPS 204 and 205",
pqcforum@list.nist.gov mailing list, 19 April 2024,
.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, .
[SPHINCSPLUS]
Aumasson, J., Bernstein, D., Beullens, W., and E. al.,
"SPHINCS+  Submission to the NIST postquantum project,
v3.1", 10 June 2022, .
Appendix A. Change Log
00: Initial draft of the document.
01: Fixed 10.2.3 Tweakable hash functions definitions. Fixed typo
in Section 6.5. Added text to help clarify inputs to the
H_msg_mtl and PRF_msg functions. Added reference to draft FIPS
205.
02: Updated algorithm IDs for alignment with draft FIPS 205.
Fixed a typo in Sections 13 and 9.1.
Harvey, et al. Expires 14 December 2024 [Page 54]
InternetDraft Merkle Tree Ladder (MTL) Mode Signatures June 2024
03: Generalized how MTL mode randomizer is generated so that the
message does not need to be an input to PRF_msg. Updated
cryptographic separation to use "prehash" domain separator format
for input to the underlying signature scheme for compatibility
with NIST's recently proposed guidance for FIPS 204 and FIPS 205
prehashing. Added security considerations on randomizer
generation and on message privacy. Other minor edits.
Acknowledgements
The authors would like to acknowledge the following individuals for
their contributions to this document: Fitzgerald Marcelin.
Authors' Addresses
J. Harvey
Verisign Labs
12061 Bluemont Way
Reston
Email: jsharvey@verisign.com
URI: https://www.verisignlabs.com/
B. Kaliski
Verisign Labs
12061 Bluemont Way
Reston
Email: bkaliski@verisign.com
URI: https://www.verisignlabs.com/
A. Fregly
Verisign Labs
12061 Bluemont Way
Reston
Email: afregly@verisign.com
URI: https://www.verisignlabs.com/
S. Sheth
Verisign Labs
12061 Bluemont Way
Reston
Email: ssheth@verisign.com
URI: https://www.verisignlabs.com/
Harvey, et al. Expires 14 December 2024 [Page 55]