]>
Hash-Based SignaturesCisco Systems13600 Dulles Technology DriveHerndon20171VAUSAmcgrew@cisco.comCisco Systems7025-2 Kit Creek RoadResearch Triangle Park27709-4987NCUSAmicurcio@cisco.com
IRTF
Crypto Forum Research Group
This note describes a digital signature system based on
cryptographic hash functions, following the seminal work in this
area of Lamport, Diffie, Winternitz, and Merkle, as adapted by
Leighton and Micali in 1995. It specifies a one-time signature
scheme and a general signature scheme. These systems provide
asymmetric authentication without using large integer
mathematics and can achieve a high security level. They are
suitable for compact implementations, are relatively simple to
implement, and naturally resist side-channel attacks. Unlike
most other signature systems, hash-based signatures would still
be secure even if it proves feasible for an attacker to build a
quantum computer.
One-time signature systems, and general purpose signature systems
built out of one-time signature systems, have been known since 1979
, were well studied in the 1990s , and have benefited from renewed attention
in the last decade. The characteristics of these signature systems
are small private and public keys and fast signature generation and
verification, but large signatures and relatively slow key generation.
In recent years there has been interest in these systems because of
their post-quantum security
and their
suitability for compact implementations.
This note describes the Leighton and Micali adaptation of the original
Lamport-Diffie-Winternitz-Merkle one-time signature system
and general
signature system with enough specificity to
ensure interoperability between implementations.
An example implementation is given in an appendix.
A signature system provides asymmetric message authentication. The
key generation algorithm produces a public/private key pair. A
message is signed by a private key, producing a signature, and a
message/signature pair can be verified by a public key. A One-Time
Signature (OTS) system can be used to sign exactly one message
securely, but cannot securely sign more than one. An N-time signature
system can be used to sign N or fewer messages securely. A Merkle
tree signature scheme is an N-time signature system that uses an OTS
system as a component. In this note we describe the Leighton-Micali
Signature (LMS) system, which is a variant of the Merkle scheme. We
denote the one-time signature scheme that it incorporates as LM-OTS.
This note is structured as follows. Notation is introduced in
. The LM-OTS signature system is described in
, and the LMS N-time signature system is
described in . Sufficient detail is
provided to ensure interoperability.
The IANA registry for these signature
systems is described in . Security
considerations are presented in .
The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in .
The LMS signing algorithm is stateful; once a particular value of the
private key is used to sign one message, it MUST NOT be used to sign
another. To make this fact explicit in the interface, we use a
functional programming approach, in which the key generation,
signing, and verification algorithms do not have any side effects.
The signing algorithm returns both a signature and a different
private key value, which can be used to sign additional messages.
The key generation algorithm takes as input an indication of the
parameters for the signature system. If it is successful, it
returns both a private key and a public key. Otherwise, it returns
an indication of failure.
The signing algorithm takes as input the message to be signed and
the current value of the private key. If successful, it returns a
signature and the next value of the private key, if there is such
a value. After the private key of an N-time signature system has
signed N messages, the signing algorithm returns the signature and
an indication that there is no next value of the private key that
can be used for signing. If unsuccessful, it returns an
indication of failure.
The verification algorithm takes as input the public key, a
message, and a signature, and returns an indication of whether or
not the signature and message pair are valid.
A message/signature pair are valid if the signature was returned by
the signing algorithm upon input of the message and the private key
corresponding to the public key; otherwise, the signature and
message pair are not valid with probability very close to one.
Bytes and byte strings are the fundamental data types. A single byte
is denoted as a pair of hexadecimal digits with a leading "0x". A
byte string is an ordered sequence of zero or more bytes and is
denoted as an ordered sequence of hexadecimal characters with a
leading "0x". For example, 0xe534f0 is a byte string with a length of
three. An array of byte strings is an ordered set, indexed starting at zero,
in which all strings have the same length.
Unsigned integers are converted into byte strings by representing them
in network byte order. To make the number of bytes in the
representation explicit, we define the functions uint8str(X),
uint16str(X), and uint32str(X), which return one, two, and four byte
values, respectively.
When a and b are real numbers, mathematical operators are defined as follows:
^ : a ^ b denotes the result 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 remainder of the integer division of a by b+ : a + b denotes the sum of a and b- : a - b denotes the difference of a and b
The standard order of operations is used when evaluating arithmetic expressions.
If A and B are bytes, then A AND B denotes the bitwise logical and
operation.
When B is a byte and i is an integer, then B >> i denotes the logical
right-shift operation.
Similarly, B << i denotes the logical left-shift operation.
If S and T are byte strings, then S || T denotes the concatenation
of S and T.
The i^th byte string in an array A is denoted as A[i].
If S is a byte string, then byte(S, i) denotes its i^th byte, where
byte(S, 0) is the leftmost byte. In addition, bytes(S, i, j) denotes the
range of bytes from the i^th to the j^th byte, inclusive. For example, if
S = 0x02040608, then byte(S, 0) is 0x02 and bytes(S, 1, 2) is 0x0406.
A byte string can be considered to be a string of w-bit unsigned
integers; the correspondence is defined by the function coef(S, i, w) as follows:
The return value of coef is an unsigned integer.
If i is larger than the number of w-bit values in S, then
coef(S, i, w) is undefined, and an attempt to compute
that value should raise an error.
To improve security against attacks that amortize their effort against
multiple invocations of the hash function H, Leighton and Micali
introduce a "security string" that is distinct for each invocation of
H. The following fields can appear in a security string:
I - an identifier for the private key. This value is 31 bytes
long, and it MUST be distinct from all other such identifiers. It
SHOULD be chosen uniformly at random, or via a pseudorandom
process, in order to ensure that it will be distinct with
probability close to one, but it MAY be a structured identifier.
D - a domain separation parameter, which is a single byte that
takes on different values in the different algorithms in which
H is invoked. D takes on the following values:
D_ITER = 0x00 in the iterations of the LM-OTS algorithms
D_PBLC = 0x01 when computing the hash of all of the
iterates in the LM-OTS algorithm
D_MESG = 0x02 when computing the hash of the message in
the LM-OTS algorithms
D_LEAF = 0x03 when computing the hash of the leaf of an LMS tree
D_INTR = 0x04 when computing the hash of an interior node
of an LMS tree
C - an n-byte randomizer that is included with the message
whenever it is being hashed to improve security. C MUST be chosen
uniformly at random, or via a pseudorandom process.
i - in the LM-OTS one-time signature scheme, i is the index of the
private key element upon which H is being applied. It is
represented as a 16-bit (two byte) unsigned integer in network byte
order.
j - in the LM-OTS one-time signature scheme, j is the iteration
number used when the private key element is being iteratively
hashed. It is represented as an 8-bit (one byte) unsigned
integer.
q - in the LM-OTS one-time signature scheme, q is a diversification
string provided as input. In the LMS N-time signature scheme, a
distinct value of q is provided for each distinct LM-OTS
public/private keypair. It is represented as a four byte string.
r - in the LMS N-time signature scheme, the node number r
associated with a particular node of the hash tree is used as an
input to the hash used to compute that node. This value is
represented as a 32-bit (four byte) unsigned integer in network
byte order.
If r is a non-negative real number, then we define the following functions:
ceil(r) : returns the smallest integer larger than rfloor(r) : returns the largest integer smaller than rlg(r) : returns the base-2 logarithm of r
This section defines LM-OTS signatures. The signature is used to validate
the authenticity of a message by associating a secret private key with
a shared public key. These are one-time signatures; each
private key MUST be used only one time to sign any given message.
As part of the signing process, a digest of the original message is
computed using the cryptographic hash function H (see ), and the resulting digest is signed.
In order to facilitate its use in an N-time signature system, the
LM-OTS key generation, signing, and verification algorithms all take
as input a diversification parameter q. When the LM-OTS signature
system is used outside of an N-time signature system, this value
SHOULD be set to the all-zero value.
The signature system uses the parameters n and w, which are both
positive integers. The algorithm description also makes use of the
internal parameters p and ls, which are dependent on n and w. These
parameters are summarized as follows:
n : the number of bytes of the output of the hash functionw : the Winternitz parameter; it is a member of the set { 1, 2, 4, 8 }p : the number of n-byte string elements that make up the LM-OTS signaturels : the number of left-shift bits used in the checksum function Cksm (defined in ).
The value of n is determined by the functions selected for use as part
of the LM-OTS algorithm; the choice of this value has a strong
effect on the security of the system. The parameter w can be chosen
to set the number of bytes in the signature; it has little effect on
security. Note however, that there is a larger computational cost to
generate and verify a shorter signature. The values of p and ls are
dependent on the choices of the parameters n and w, as described in
. A table illustrating various
combinations of n, w, p, and ls is provided in .
The LM-OTS algorithm uses a hash function H that accepts byte strings of
any length, and returns an n-byte string.
To fully describe a LM-OTS signature method, the parameters n and
w, as well as the function H, MUST be specified. This section defines
several LM-OTS signature systems, each of which is identified by a
name. Values for p and ls are provided as a convenience.
NameHnwplsLMOTS_SHA256_N32_W1SHA2563212657LMOTS_SHA256_N32_W2SHA2563221336LMOTS_SHA256_N32_W4SHA256324674LMOTS_SHA256_N32_W8SHA256328340LMOTS_SHA256_N16_W1SHA256-16161688LMOTS_SHA256_N16_W2SHA256-16162688LMOTS_SHA256_N16_W4SHA256-16164354LMOTS_SHA256_N16_W8SHA256-16168180
Here SHA256 denotes the NIST standard hash function . SHA256-16 denotes the SHA256 hash function with
its final output truncated to return the leftmost 16 bytes.
The LM-OTS private key consists of an array of size p containing n-byte
strings. Let x denote the private key. This
private key must be used to sign one and only one message. It must
therefore be unique from all other private keys. The following
algorithm shows pseudocode for generating x.
An implementation MAY use a pseudorandom method to compute x[i], as
suggested in , page 46. The details of the
pseudorandom method do not affect interoperability, but the
cryptographic strength MUST match that of the LM-OTS algorithm.
The LM-OTS public key is generated from the private key by iteratively
applying the function H to each individual element of x, for 2^w - 1
iterations, then hashing all of the resulting values.
Each public/private key pair is associated with a single identifier
I. This string MUST be 31 bytes long, and be generated as described
in .
The diversification parameter q is an input to the algorithm, as
described in .
The following algorithm shows pseudocode for
generating the public key, where the array x is the private key.
The public key is the string consisting of a four-byte enumeration
that identifies the parameters in use, followed by the value
returned by Algorithm 1. specifies the
enumeration and more formally defines the format.
A checksum is used to ensure that any forgery attempt that manipulates
the elements of an existing signature will be detected. The security
property that it provides is detailed in .
The checksum function Cksm is defined as follows, where S denotes
the byte string that is input to that function, and the value
sum is a 16-bit unsigned integer:
The LM-OTS signature of a message is generated by first appending the
randomizer C, the identifier string I, and the diversification string
q to the message, then using H to compute the hash of the resulting
string, concatenating the checksum of the hash to the hash itself,
then considering the resulting value as a sequence of w-bit values,
and using each of the the w-bit values to determine the number of
times to apply the function H to the corresponding element of the
private key. The outputs of the function H are concatenated together
and returned as the signature. The pseudocode for this procedure is
shown below.
The identifier string I and diversification string q are
the same as in .
The signature is the string consisting of a four-byte enumeration
that identifies the parameters in use, followed by the value
returned by Algorithm 3. specifies the
enumeration and more formally defines the format.
In order to verify a message with its signature (an array of n-byte
strings, denoted as y), the receiver must "complete" the series of
applications of H using the w-bit values of the message hash and its
checksum. This computation should result in a value that matches the
provided public key.
A future version of this specification may
define a method for computing the signature
of a very short message in which the hash
is not applied to the message during
the signature computation. That
would allow the signatures to have reduced size.
Though the data formats are formally defined by XDR, we include
diagrams as well as a convenience to the reader. An example of the
format of an lmots_signature is illustrated below, for
lmots_sha256_n32_w1. An ots_signature consists of a 32-bit unsigned
integer that indicates the ots_algorithm_type, followed by other data,
whose format depends only on the ots_algorithm_type. For
LM-OTS, that data is an array of equal-length byte strings. The number
of bytes in each byte string, and the number of elements in the array,
are determined by the ots_algorithm_type field. In the case of
lmots_sha256_n32_w1, the array has 265 elements, each of which is a
32-byte string. The XDR array y_n32_p265 denotes the array y as used
in the algorithm descriptions above, using the parameters of n=32 and
p=265 for lmots_sha256_n32_w1.
A verifier MUST check the ots_algorithm_type field, and a
verification operation on a signature with an unknown
lmots_algorithm_type MUST return FAIL.
The Leighton Micali Signature (LMS) method can sign a potentially large
but fixed number of messages. An LMS system uses two cryptographic
components: a one-time signature method and a hash function. Each LMS
public/private key pair is associated with a perfect binary tree, each
node of which contains an n-byte value. Each leaf of the tree
contains the value of the public key of an LM-OTS public/private key
pair. The value contained by the root of the tree is the LMS public
key. Each interior node is computed by applying the hash function to
the concatenation of the values of its children nodes.
An LMS system has the following parameters:
h : the height (number of levels - 1) in the tree, and
n : the number of bytes associated with each node.
There are 2^h leaves in the tree.
An LMS private key consists of 2^h one-time signature private keys
and the leaf number of the next LM-OTS private key that has not yet
been used. The leaf number is initialized to zero when the LMS
private key is created.
An LMS private key MAY be generated pseudorandomly from a secret
value, in which case the secret value MUST be at least n bytes long, be
uniformly random, and MUST NOT be used for any other purpose than
the generation of the LMS private key. The details of how this
process is done do not affect interoperability; that is, the public
key verification operation is independent of these details.
An LMS public key is defined as follows, where we denote the public
key associated with the i^th LM-OTS private key as OTS_PUBKEY[i], with
i ranging from 0 to (2^h)-1. Each instance of an LMS public/private
key pair is associated with a perfect binary tree, and the nodes of
that tree are indexed from 1 to 2^(h+1)-1. Each node is associated with
an n-byte string, and the string for the rth node is denoted as T[r]
and is defined as
The LMS public key is the string consisting of a four-byte
enumeration that identifies the parameters in use, followed by the
string T[1]. specifies the enumeration and
more formally defines the format. The value T[1] can be computed
via recursive application of the above equation, or by any
equivalent method. An iterative procedure is outlined in .
An LMS signature consists of
a typecode indicating the particular LMS algorithm,
an LM-OTS signature, and
an array of values that is associated with the path through the
tree from the leaf associated with the LM-OTS signature to the
root.
The array of values contains the siblings of the nodes on the path
from the leaf to the root but does not contain the nodes on the path
itself. The array for a tree with height h will have h values. The
first value is the sibling of the leaf, the next value is the sibling
of the parent of the leaf, and so on up the path to the root.
To compute the LMS signature of a message with an LMS private key,
the signer first computes the LM-OTS signature of the message
using the leaf number of the next unused LM-OTS private key.
Before releasing the signature, the leaf number in the LMS private
key MUST be incremented to prevent the LM-OTS private key from
being used again. The node number in the signature is set to the
leaf number of the LMS private key that was used in the signature.
Then the signature and the LMS private key are returned.
The array of node values in the signature MAY be computed in any
way. There are many potential time/storage tradeoffs that can be
applied. The fastest alternative is to store all of the nodes of
the tree and set the array in the signature by copying them. The
least storage intensive alternative is to recompute all of the
nodes for each signature. Note that the details of this procedure
are not important for interoperability; it is not necessary to
know any of these details in order to perform the signature
verification operation. The internal nodes of the tree need not
be kept secret, and thus a node-caching scheme that stores only
internal nodes can sidestep the need for strong protections.
One useful time/storage tradeoff is described in Column 19 of
.
An LMS signature is verified by first using the LM-OTS signature
verification algorithm to compute the LM-OTS public key from the LM-OTS
signature and the message. The value of that public key
is then assigned to the associated leaf of the LMS tree,
then the root of the tree is computed from the leaf value
and the node array (path[]) as described below. If the root
value matches the public key, then the signature is valid;
otherwise, the signature fails.
The verifier MAY cache interior node values that have been computed
during a successful signature verification for use in
subsequent signature verifications. However, any implementation
that does so MUST make sure any nodes that are cached during
a signature verification process are deleted if that
process does not result in a successful match between
the root of the tree and the LMS public key.
In scenarios where it is necessary to minimize the time taken by the
public key generation process, a hierarchical N-time signature scheme
can be used. Leighton and Micali describe a scheme in which an LMS
public key is used to sign a second LMS public key, which is then
distributed along with the signatures generated with the second public
key . This hierarchical scheme, which we
describe in this section, uses an LMS scheme as a component, and it
has two levels. Each level is associated with an LMS public key,
private key, and signature. The following notation is used, where i
is an integer between 1 and 2 inclusive:
prv[i] is the private key of the ith level,
pub[i] is the public key of the ith level, and
sig[i] is the signature of the ith level.
In this section, we say that an N-time private key is exhausted when
it has signed all N messages, and thus it can no longer be used for
signing.
To generate an HLMS private and public key pair, new LMS private and
public keys are generated for prv[i] and pub[i] for i=1,2. These
key pairs MUST be generated independently.
The public key of the HLMS scheme is pub[1], the public key of the
first level. The HLMS private key consists of prv[1] and prv[2].
The values pub[1] and prv[1] do not change, though the values of
pub[2] and prv[2] are dynamic, and are changed by the signature
generation algorithm.
To sign a message using the private key prv, the following
steps are performed:
The message is signed with prv[2], and the value sig[2] is set to
that result.
The value of the HLMS signature is set to type || pub[2] || sig[1] || sig[2],
where type is the typecode for the particular HLMS algorithm.
If prv[2] is exhausted, then a new LMS public and private key pair
is generated, and pub[2] and prv[2] are set to those values.
pub[2] is signed with prv[1], and sig[1] is set to the resulting
value.
To verify a signature sig and message using the public key pub, the
following steps are performed:
The signature sig is parsed into its components type, pub[2],
sig[1] and sig[2].
The signature sig[2] and message is verified using the public key
pub[2]. If verification fails, then an indication of failure is
returned. Otherwise, processing continues as follows.
The signature sig[1] of the "message" pub[2] is verified using the
public key pub. If verification fails, then an indication of
failure is returned. Otherwise, an indication of success is
returned.
The goal of this note is to describe the LM-OTS and LMS algorithms
following the original references and present the modern security
analysis of those algorithms. Other signature methods are out of
scope and may be interesting follow-on work.
We adopt the techniques described by Leighton and Micali to mitigate
attacks that amortize their work over multiple invocations of the
hash function.
The values taken by the identifier I across different LMS
public/private key pairs are required to be distinct in order to
improve security. That distinctness ensures the uniqueness of the
inputs to H across all of those public/private key pair instances,
which is important for provable security in the random oracle model.
The length of I is set at 31 bytes so that randomly chosen values of
I will be distinct with probability at least 1 - 1/2^128 as long as
there are 2^60 or fewer instances of LMS public/private key pairs.
The sizes of the parameters in the security string are such that,
for n=16, the LM-OTS iterates a 55-byte value (that is, the string
that is input to H() during the iteration over j during signature
generation and verification is 55 bytes long). Thus, when SHA-256
is used as the function H, only a single invocation of its
compression function is needed.
The signature and public key formats are designed so that they are
easy to parse. Each format starts with a 32-bit enumeration value
that indicates all of the details of the signature algorithm and hence
defines all of the information that is needed in order to parse the
format.
The Checksum is calculated using a
non-negative integer "sum", whose width was chosen to be an integer
number of w-bit fields such that it is capable of holding the
difference of the total possible number of applications of the
function H as defined in the signing algorithm of and the total actual number. In the worst
case (i.e. the actual number of times H is iteratively applied is 0),
the sum is (2^w - 1) * ceil(8*n/w). Thus for the purposes of this
document, which describes signature methods based on H = SHA256 (n =
32 bytes) and w = { 1, 2, 4, 8 }, the sum variable is a 16-bit
non-negative integer for all combinations of n and w. The calculation
uses the parameter ls defined in and
calculated in , which indicates the
number of bits used in the left-shift operation.
This is the third version version of this draft. It has the
following changes:
It adopts the "security string" approach of Leighton and Micali
in order to improve security.
It adopts Leighton and Micali's idea of hashing a randomizer string
(C, as defined in ) with the message, so
that finding an arbitrary collision in H will not lead to a
forgery.
It defines a multi-level signature scheme, again following that
described by Leighton and Micali.
It eliminates the function F and its iterates; the function H is
used in its stead. The adoption of the security string makes this
simplification possible.
It fixes the branching number at two for simplicity.
This section is to be removed by the RFC editor upon publication.
The Internet Assigned Numbers Authority (IANA) is requested to create
two registries: one for OTS signatures, which includes all of the
LM-OTS signatures as defined in Section 3, and one for Leighton-Micali
Signatures, as defined in Section 4. Additions to these registries
require that a specification be documented in an RFC or another
permanent and readily available reference in sufficient detail that
interoperability between independent implementations is possible.
Each entry in the registry contains the following elements:
a short name, such as "LMS_SHA256_n32_h10", a positive number, anda reference to a specification that completely defines the
signature method test cases that can be used to verify the
correctness of an implementation.
Requests to add an entry to the registry MUST include the name and the
reference. The number is assigned by IANA. These number assignments
SHOULD use the smallest available palindromic number. Submitters
SHOULD have their requests reviewed by the IRTF Crypto Forum Research
Group (CFRG) at cfrg@ietf.org. Interested applicants that are
unfamiliar with IANA processes should visit http://www.iana.org.
The numbers between 0xDDDDDDDD (decimal 3,722,304,989) and
0xFFFFFFFF (decimal 4,294,967,295) inclusive, will not be
assigned by IANA, and are reserved for private use; no attempt
will be made to prevent multiple sites from using the same
value in different (and incompatible) ways
.
The LM-OTS registry is as follows.
NameReferenceNumeric Identifier LMOTS_SHA256_N16_W1 0x00000001 LMOTS_SHA256_N16_W2 0x00000002 LMOTS_SHA256_N16_W4 0x00000003 LMOTS_SHA256_N16_W8 0x00000004 LMOTS_SHA256_N32_W1 0x00000005 LMOTS_SHA256_N32_W2 0x00000006 LMOTS_SHA256_N32_W4 0x00000007 LMOTS_SHA256_N32_W8 0x00000008
The LMS registry is as follows.
NameReferenceNumeric Identifier LMS_SHA256_N32_H20 0x00000001 LMS_SHA256_N32_H10 0x00000002 LMS_SHA256_N32_H5 0x00000003 LMS_SHA256_N16_H20 0x00000004 LMS_SHA256_N16_H10 0x00000005 LMS_SHA256_N16_H5 0x00000006
An IANA registration of a signature system does not constitute an
endorsement of that system or its security.
The security goal of a signature system is to prevent forgeries. A
successful forgery occurs when an attacker who does not know the
private key associated with a public key can find a message and
signature that are valid with that public key (that is, the Signature
Verification algorithm applied to that signature and message and
public key will return "valid"). Such an attacker, in the strongest
case, may have the ability to forge valid signatures for an
arbitrary number of other messages.
LM-OTS and LMS are provably secure in the random oracle model, as
shown by Katz . From Theorem 8 of that
reference:
For any adversary attacking arbitrarily many instances of the
one-time signature scheme, and making at most q hash queries, the
probability with which the adversary is able to forge a signature
with respect to any of the instances is at most q2^(1-8n).
Here n is the number of bytes in the output of the hash function (as
defined in ). Thus, the security of the
algorithms defined in this note can be roughly described as follows.
For a security level of roughly 128 bits, assuming that there are no
quantum computers, use n=16 by selecting an algorithm identifier with
N16 in its name. For a security level of roughly 128 bits, assuming
that there are quantum computers that can compute the input to an
arbitrary function with computational cost equivalent to the square
root of the size of the domain of that function , use n=32 by selecting an algorithm identifier
with N32 in its name.
The LMS signature system, like all N-time signature systems,
requires that the signer maintain state across different invocations
of the signing algorithm, to ensure that none of the component
one-time signature systems are used more than once. This section
calls out some important practical considerations around this
statefulness.
In a typical computing environment, a private key will be stored in
non-volatile media such as on a hard drive. Before it is used to
sign a message, it will be read into an application's Random Access
Memory (RAM). After a signature is generated, the value of the
private key will need to be updated by writing the new value of the
private key into non-volatile storage. It is essential for security
that the application ensure that this value is actually written into
that storage, yet there may be one or more memory caches between it
and the application. Memory caching is commonly done in the file
system, and in a physical memory unit on the hard disk that is
dedicated to that purpose. To ensure that the updated value is
written to physical media, the application may need to take several
special steps. In a POSIX environment, for instance,the O_SYNC flag
(for the open() system call) will cause invocations of the write()
system call to block the calling process until the data has been to
the underlying hardware. However, if that hardware has its own
memory cache, it must be separately dealt with using an operating
system or device specific tool such as hdparm to flush the on-drive
cache, or turn off write caching for that drive. Because these
details vary across different operating systems and devices, this
note does not attempt to provide complete guidance; instead, we call
the implementer's attention to these issues.
When hierarchical signatures are used, an easy way to minimize the
private key synchronization issues is to have the private key for
the second level resident in RAM only, and never write that value
into non-volatile memory. A new second level public/private key
pair will be generated whenever the application (re)starts; thus,
failures such as a power outage or application crash are
automatically accommodated. Implementations SHOULD use this approach
wherever possible.
To show the security of LM-OTS checksum, we consider the signature y of
a message with a private key x and let h = H(message) and
c = Cksm(H(message)) (see ). To attempt
a forgery, an attacker may try to change the values of h and c. Let
h' and c' denote the values used in the forgery attempt. If for some integer j
in the range 0 to (u-1), inclusive,
a' = coef(h', j, w),
a = coef(h, j, w), and
a' > a
then the attacker can compute F^a'(x[j]) from F^a(x[j]) = y[j] by
iteratively applying function F to the j^th term of the signature an
additional (a' - a) times. However, as a result of the increased
number of hashing iterations, the checksum value c' will decrease
from its original value of c. Thus a valid signature's checksum will
have, for some number k in the range u to (p-1), inclusive,
b' = coef(c', k, w),
b = coef(c, k, w), and
b' < b
Due to the one-way property of F, the attacker cannot easily compute F^b'(x[k])
from F^b(x[k]) = y[k].
Thanks are due to Chirag Shroff, Andreas Hulsing, Burt Kaliski, Eric
Osterweil, Ahmed Kosba, Russ Housley, and Scott Fluhrer for
constructive suggestions and valuable detailed review. We esepcially
acknowledge Jerry Solinas, Laurie Law, and Kevin Igoe, who pointed out
the security benefits of the approach of Leighton and Micali and Jonathan Katz, who gave us security
guidance.
&rfc2119;
&rfc2434;
&rfc4506;
Secure Hash Standard (SHS)National Institute of Standards and TechnologyLarge provably fast and secure digital signature schemes from secure hash functionsAnalysis of a proposed hash-based signature standardA fast quantum mechanical algorithm for database searchA Certified Digital SignatureOne Way Hash Functions and DESA Digital Signature Based on a Conventional Encryption FunctionSecrecy, Authentication, and Public Key Systems
A table illustrating various combinations of n and w with the associated values of
u, v, ls, and p is provided in
.
Hash Length in Bytes (n)Winternitz Parameter (w)w-bit Elements in Hash (u)w-bit Elements in Checksum (v)Left Shift (ls)Total Number of w-bit Elements (p)161128881371626448681643234351681620183212569726532212856133324643467328322034
The LMS public key can be computed using the following algorithm or
any equivalent method. The algorithm uses a stack of hashes for data
and a separate stack of integers to keep track of the level of the
tree. It also makes use of a hash function with the typical
init/update/final interface to hash functions; the result of the
invocations hash_init(), hash_update(N[1]), hash_update(N[2]), ... ,
hash_update(N[n]), v = hash_final(), in that order, is identical to
that of the invocation of H(N[1] || N[2] || ... || N[n]).