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

Errata ID: 8534
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: François Dupressoir
Date Reported: 2025-08-19
Held for Document Update by: Nick Sullivan
Date Held: 2026-01-28

Section 3.1.1 says:

Choices of w are limited to the values 4 and 16 since these values yield 
optimal trade-offs and easy implementation.

It should say:

Choices of w are limited to the values 4 and 16 since these values yield 
optimal trade-offs and easy implementation.

NOTE: Instantiating w and n with values not specified here may require changes
to the algorithms as they are described in this RFC, for correctness and
security. In particular, Algorithm 1 (Section 2.6) is incorrect for values of w
larger than 256. Algorithms 5 and 6 (Sections 3.1.5 and 3.1.6) yield an insecure 
signature scheme when instantiated with parameters n and w such that len_2 *
lg(w) is divisible by 8 (for example, with w = 256 and any value of n).

Notes:

This additional note aims at future-proofing the RFC against unchecked extensions to the parameter set. Algorithm 1 when w > 256 may lead to an insecure instantiation. Instantiating Algorithms 5 and 6 with w = 256 (and any value of n) or some other (n, w) pair such that len_2 * lg(w) is divisible by 8 leads to immediate forgery attacks: the value of csum gets multiplied by 2^8 (shifted left by 8), but its big-endian encoding (with toByte) does not take this into account and drops the most significant base w word(s) of the checksum.

--VERIFIER NOTES--
The erratum proposes adding a cautionary note about parameter values outside the specified range (w not in {4,16}). RFC author Huelsing agrees the content is correct, but this adds new guidance rather than correcting an error, so it belongs in a document revision: https://mailarchive.ietf.org/arch/msg/cfrg/i-p4Up1VvZ40loKThQNHsURbYJg/

Report New Errata