< draft-irtf-cfrg-xmss-hash-based-signatures-11.txt   draft-irtf-cfrg-xmss-hash-based-signatures-12.txt >
Crypto Forum Research Group A. Huelsing Crypto Forum Research Group A. Huelsing
Internet-Draft TU Eindhoven Internet-Draft TU Eindhoven
Intended status: Informational D. Butin Intended status: Informational D. Butin
Expires: June 16, 2018 TU Darmstadt Expires: July 14, 2018 TU Darmstadt
S. Gazdag S. Gazdag
genua GmbH genua GmbH
J. Rijneveld J. Rijneveld
Radboud University Radboud University
A. Mohaisen A. Mohaisen
University of Central Florida University of Central Florida
December 13, 2017 January 10, 2018
XMSS: Extended Hash-Based Signatures XMSS: Extended Hash-Based Signatures
draft-irtf-cfrg-xmss-hash-based-signatures-11 draft-irtf-cfrg-xmss-hash-based-signatures-12
Abstract Abstract
This note describes the eXtended Merkle Signature Scheme (XMSS), a This note describes the eXtended Merkle Signature Scheme (XMSS), a
hash-based digital signature system. It follows existing hash-based digital signature system. It follows existing
descriptions in scientific literature. The note specifies the WOTS+ descriptions in scientific literature. The note specifies the WOTS+
one-time signature scheme, a single-tree (XMSS) and a multi-tree one-time signature scheme, a single-tree (XMSS) and a multi-tree
variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main
building block. XMSS provides cryptographic digital signatures building block. XMSS provides cryptographic digital signatures
without relying on the conjectured hardness of mathematical problems. without relying on the conjectured hardness of mathematical problems.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 16, 2018. This Internet-Draft will expire on July 14, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 28 skipping to change at page 3, line 28
5. Parameter Sets . . . . . . . . . . . . . . . . . . . . . . . 40 5. Parameter Sets . . . . . . . . . . . . . . . . . . . . . . . 40
5.1. Implementing the functions . . . . . . . . . . . . . . . 40 5.1. Implementing the functions . . . . . . . . . . . . . . . 40
5.2. WOTS+ Parameters . . . . . . . . . . . . . . . . . . . . 42 5.2. WOTS+ Parameters . . . . . . . . . . . . . . . . . . . . 42
5.3. XMSS Parameters . . . . . . . . . . . . . . . . . . . . . 42 5.3. XMSS Parameters . . . . . . . . . . . . . . . . . . . . . 42
5.3.1. Parameter guide . . . . . . . . . . . . . . . . . . . 43 5.3.1. Parameter guide . . . . . . . . . . . . . . . . . . . 43
5.4. XMSS^MT Parameters . . . . . . . . . . . . . . . . . . . 44 5.4. XMSS^MT Parameters . . . . . . . . . . . . . . . . . . . 44
5.4.1. Parameter guide . . . . . . . . . . . . . . . . . . . 46 5.4.1. Parameter guide . . . . . . . . . . . . . . . . . . . 46
6. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7. Reference Code . . . . . . . . . . . . . . . . . . . . . . . 49 7. Reference Code . . . . . . . . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53
9.1. Security Proofs . . . . . . . . . . . . . . . . . . . . . 53 9.1. Security Proofs . . . . . . . . . . . . . . . . . . . . . 53
9.2. Minimal Security Assumptions . . . . . . . . . . . . . . 54 9.2. Minimal Security Assumptions . . . . . . . . . . . . . . 55
9.3. Post-Quantum Security . . . . . . . . . . . . . . . . . . 54 9.3. Post-Quantum Security . . . . . . . . . . . . . . . . . . 55
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.1. Normative References . . . . . . . . . . . . . . . . . . 55 11.1. Normative References . . . . . . . . . . . . . . . . . . 56
11.2. Informative References . . . . . . . . . . . . . . . . . 56 11.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. WOTS+ XDR Formats . . . . . . . . . . . . . . . . . 57 Appendix A. WOTS+ XDR Formats . . . . . . . . . . . . . . . . . 58
Appendix B. XMSS XDR Formats . . . . . . . . . . . . . . . . . . 58 Appendix B. XMSS XDR Formats . . . . . . . . . . . . . . . . . . 59
Appendix C. XMSS^MT XDR Formats . . . . . . . . . . . . . . . . 63 Appendix C. XMSS^MT XDR Formats . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction 1. Introduction
A (cryptographic) digital signature scheme provides asymmetric A (cryptographic) digital signature scheme provides asymmetric
message authentication. The key generation algorithm produces a key message authentication. The key generation algorithm produces a key
pair consisting of a private and a public key. A message is signed pair consisting of a private and a public key. A message is signed
using a private key to produce a signature. A message/signature pair using a private key to produce a signature. A message/signature pair
can be verified using a public key. A One-Time Signature (OTS) can be verified using a public key. A One-Time Signature (OTS)
scheme allows using a key pair to sign exactly one message securely. scheme allows using a key pair to sign exactly one message securely.
A Many-Time Signature (MTS) system can be used to sign multiple A Many-Time Signature (MTS) system can be used to sign multiple
skipping to change at page 49, line 25 skipping to change at page 49, line 25
8. IANA Considerations 8. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to create The Internet Assigned Numbers Authority (IANA) is requested to create
three registries: one for WOTS+ signatures as defined in Section 3, three registries: one for WOTS+ signatures as defined in Section 3,
one for XMSS signatures and one for XMSS^MT signatures; the latter one for XMSS signatures and one for XMSS^MT signatures; the latter
two being defined in Section 4. For the sake of clarity and two being defined in Section 4. For the sake of clarity and
convenience, the first sets of WOTS+, XMSS, and XMSS^MT parameter convenience, the first sets of WOTS+, XMSS, and XMSS^MT parameter
sets are defined in Section 5. Additions to these registries require sets are defined in Section 5. Additions to these registries require
that a specification be documented in an RFC or another permanent and that a specification be documented in an RFC or another permanent and
readily available reference in sufficient detail to make readily available reference in sufficient detail as defined by the
"Specification Required" policy described in [RFC8126] to make
interoperability between independent implementations possible. Each interoperability between independent implementations possible. Each
entry in the registry contains the following elements: entry in the registry contains the following elements:
a short name, such as "XMSS_SHA2_20_256", a short name, such as "XMSS_SHA2_20_256",
a positive number, and a positive number, and
a reference to a specification that completely defines the a reference to a specification that completely defines the
signature method test cases that can be used to verify the signature method test cases or provides (a reference to) a
reference implementation that can be used to verify the
correctness of an implementation. correctness of an implementation.
Requests to add an entry to the registry MUST include the name and Requests to add an entry to the registry MUST include the name and
the reference. The number is assigned by IANA. These number the reference. The number is assigned by IANA. These number
assignments SHOULD use the smallest available positive number. assignments SHOULD use the smallest available positive number.
Submitters SHOULD have their requests reviewed by the IRTF Crypto Submitters MUST have their requests reviewed and approved.
Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants Designated Experts for this task as requested by the the
that are unfamiliar with IANA processes should visit "Specification Required" policy defined by [RFC8126] will be assigned
http://www.iana.org. by the Internet Engineering Steering Group (IESG). The IESG can be
contacted via iesg@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 The numbers between 0xDDDDDDDD (decimal 3,722,304,989) and 0xFFFFFFFF
(decimal 4,294,967,295) inclusive, will not be assigned by IANA, and (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 are reserved for private use; no attempt will be made to prevent
multiple sites from using the same value in different (and multiple sites from using the same value in different (and
incompatible) ways [RFC8126]. incompatible) ways [RFC8126].
The WOTS+ registry is as follows. The WOTS+ registry is as follows.
+-----------------+-------------+--------------------+ +-----------------+-------------+--------------------+
skipping to change at page 57, line 11 skipping to change at page 57, line 43
Kaliski, B., "Panel: Shoring up the Infrastructure: A Kaliski, B., "Panel: Shoring up the Infrastructure: A
Strategy for Standardizing Hash Signatures", NIST Workshop Strategy for Standardizing Hash Signatures", NIST Workshop
on Cybersecurity in a Post-Quantum World, 2015. on Cybersecurity in a Post-Quantum World, 2015.
[KMN14] Knecht, M., Meier, W., and C. Nicola, "A space- and time- [KMN14] Knecht, M., Meier, W., and C. Nicola, "A space- and time-
efficient Implementation of the Merkle Tree Traversal efficient Implementation of the Merkle Tree Traversal
Algorithm", Computing Research Repository Algorithm", Computing Research Repository
(CoRR). arXiv:1409.4081, 2014. (CoRR). arXiv:1409.4081, 2014.
[MCF17] McGrew, D., Curcio, M., and S. Fluhrer, "Hash-Based [MCF17] McGrew, D., Curcio, M., and S. Fluhrer, "Hash-Based
Signatures", Work in Progress, draft-mcgrew-hash-sigs-07, Signatures", Work in Progress, draft-mcgrew-hash-sigs-08,
June 2017, <http://www.ietf.org/archive/id/ October 2017, <http://www.ietf.org/archive/id/
draft-mcgrew-hash-sigs-07.txt>. draft-mcgrew-hash-sigs-08.txt>.
[Merkle79] [Merkle79]
Merkle, R., "Secrecy, Authentication, and Public Key Merkle, R., "Secrecy, Authentication, and Public Key
Systems", Stanford University Information Systems Systems", Stanford University Information Systems
Laboratory Technical Report 1979-1, 1979, Laboratory Technical Report 1979-1, 1979,
<http://www.merkle.com/papers/Thesis1979.pdf>. <http://www.merkle.com/papers/Thesis1979.pdf>.
Appendix A. WOTS+ XDR Formats Appendix A. WOTS+ XDR Formats
The WOTS+ signature and public key formats are formally defined using The WOTS+ signature and public key formats are formally defined using
 End of changes. 12 change blocks. 
24 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/