RFC Errata
Found 8 records.
Status: Verified (4)
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)
Errata ID: 7412
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafael Misoczki
Date Reported: 2023-04-02
Verifier Name: Colin Perkins
Date Verified: 2023-04-10
Section 2.6 (Algorithm 1) says:
bits += 8;
It should say:
bits = 8;
Notes:
"bits += 8;" is misleading and results in one useless addition.
This is true because this instruction appears after the program ensured that "bits == 0".
Therefore, "bits = 8;" is the actual instruction that should be executed here.
Status: Reported (4)
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.
Errata ID: 6821
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Gordon
Date Reported: 2022-01-24
Section 3.1.5 says:
"Note that the checksum may reach a maximum integer value of len_1 * (w - 1) * 2^8"
It should say:
"Note that the checksum may reach a maximum integer value of len_1 * (w - 1)"
Notes:
The "* 2^8" appears to be a mistake. If the checksum integers could reach those values, the checksum field would overflow, which would potentially allow an attacker to forge a message.
In reality, the correct maximum is just "len_1 * (w - 1)"
Errata ID: 7420
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafael Misoczki
Date Reported: 2023-04-11
Section 4.2.2 says:
// Generate reduced XMSS private keys
ADRS = toByte(0, 32);
for ( layer = 0; layer < d; layer++ ) {
ADRS.setLayerAddress(layer);
for ( tree = 0; tree <
(1 << ((d - 1 - layer) * (h / d)));
tree++ ) {
ADRS.setTreeAddress(tree);
for ( i = 0; i < 2^(h / d); i++ ) {
wots_sk[i] = WOTS_genSK();
}
setXMSS_SK(SK_MT, wots_sk, tree, layer);
}
}
It should say:
// Generate reduced XMSS private keys
ADRS = toByte(0, 32);
for ( layer = 0; layer < d; layer++ ) {
ADRS.setLayerAddress(layer);
for ( tree = 0; tree <
(1 << ((d - 1 - layer) * (h / d)));
tree++ ) {
ADRS.setTreeAddress(tree);
for ( i = 0; i < 2^(h / d); i++ ) {
wots_sk[i] = WOTS_genSK();
}
setXMSS_SK(SK_MT, wots_sk, tree, layer, ADRS);
}
}
Notes:
The ADRS variable is created and configured (layer address and tree address fields set) but it is not used anywhere in the for-loop.
It would be more precise if the setXMSS_SK function receives the ADRS variable so that implementers understand that both layer address and tree address fields must be set as defined in this for-loop in order to generate the correct XMSS private key in each iteration of this loop.
Errata ID: 7900
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Çağdaş Çalık
Date Reported: 2024-04-18
Section 4.1.3 says:
An XMSS private key SK contains 2^h WOTS+ private keys, the leaf index idx of the next WOTS+ private key that has not yet been used, SK_PRF (an n-byte key to generate pseudorandom values for randomized message hashing), the n-byte value root (which is the root node of the tree and SEED), and the n-byte public seed used to pseudorandomly generate bitmasks and hash function keys.
It should say:
An XMSS private key SK contains 2^h WOTS+ private keys, the leaf index idx of the next WOTS+ private key that has not yet been used, SK_PRF (an n-byte key to generate pseudorandom values for randomized message hashing), the n-byte value root (which is the root node of the tree), and SEED (the n-byte public seed used to pseudorandomly generate bitmasks and hash function keys).
Notes:
SEED appearing in the parenthesis explaining the root value is confusing. It has to be paired with the explanation of it that follows.