RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (3)

RFC 8391, "XMSS: eXtended Merkle Signature Scheme", May 2018

Source of RFC: IRTF

Errata ID: 5572
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Franziskus Kiefer
Date Reported: 2018-12-10
Verifier Name: Colin Perkins
Date Verified: 2019-04-09

Section 4.1.5 says:

Input: WOTS+ public key pk, address ADRS, seed SEED

It should say:

Input: WOTS+ public key pk, seed SEED, address ADRS

Notes:

ltree is called twice as ltree(pk, seed, adr).

Errata ID: 5573
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Franziskus Kiefer
Date Reported: 2018-12-10
Verifier Name: Colin Perkins
Date Verified: 2019-04-09

Section 4.1.6 says:

Output: n-byte root node - top node on Stack

It should say:

Output: n-byte root node - top node on Stack or -1

Notes:

The algorithm can fail and might return -1 instead of a root node

Errata ID: 6024
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Andreas Hülsing
Date Reported: 2020-03-18
Verifier Name: Colin Perkins
Date Verified: 2020-06-23

Section 5 says:

This section provides basic parameter sets that are assumed to cover most relevant applications.  Parameter sets for two classical security levels are defined.  Parameters with n = 32 provide a classical security level of 256 bits.  Parameters with n = 64 provide a classical security level of 512 bits.  Considering quantum-computer-aided attacks, these output sizes yield post-quantum security of 128 and 256 bits, respectively.

It should say:

This section provides basic parameter sets that are assumed to cover most relevant applications. Parameter sets for two classical security levels are defined using the cryptographic functions SHA2 and SHAKE.  Parameters with SHA2 and n = 32 provide a classical security level of 256 bits. Parameters with SHA2 and n = 64 provide a classical security level of 512 bits.  Considering quantum-computer-aided attacks, these parameters yield post-quantum security of 128 and 256 bits, respectively. Parameters with SHAKE and n = 32 provide a classical security level of 128 bits.  Parameters with SHAKE and n = 64 provide a classical security level of 256 bits.  Considering quantum-computer-aided attacks, these parameters yield post-quantum security of 86 and 170 bits, respectively. 

Notes:

Traditionally, a hash function with n-bit outputs is assumed to have n-bit security against classical preimage and second-preimage attacks, and n/2-bit security against classical collision attacks. For adversaries with access to a quantum computer, these bounds change to n/2 and n/3 bits when only counting queries to the hash function. This also applies to SHA2 and SHA3. In contrast, SHAKE follows a different reasoning. SHAKE with an internal state of n bits and an output length of n bits achieves n/2 bit security against classical preimage, second-preimage and collision attacks. For quantum attacks security changes to n/3 bits. The reason is that SHAKE allows for meet-in-the-middle preimage attacks that reduce to a collision search on the internal state.

In consequence, SHAKE-128 cannot provide more security than NIST post-quantum security level II.

(Errata submitted by Andreas Hülsing; notes slightly revised after Crypto Forum review by Scott Fluhrer; verified by CFRG Chairs and IRTF Chair)

Status: Reported (1)

RFC 8391, "XMSS: eXtended Merkle Signature Scheme", May 2018

Source of RFC: IRTF

Errata ID: 6352
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Andreas Kretschmer
Date Reported: 2020-12-09

Section Appendix A says:

The WOTS+ signature and public key formats are formally defined using
XDR [RFC4506] in order to provide an unambiguous, machine readable
definition. 

It should say:

The WOTS+ signature and public key formats are defined in a syntax similar to XDR [RFC4506].

Notes:

The definition is not machine readable, e.g. github.com/stellar/xdrgen fails.
Reason:
- some Identifiers contain "/" and "-", RFC4506 allows only letter, digits and underbars
- some enum bodies end with ",}", RFC4506 requests "}" here
- some discriminated union definitions have incomplete declarations in the case-spec, e.g. the union xmss_ots_signature refers to the wotsp-sha2_256 without giving a type.
- The encoding of some unions in the reference implementation is different to the encoding specified in RFC4506. The 4-byte discriminant is missing.

Report New Errata