On Fri, Jun 26, 2026 at 9:26 AM Niels Möller nisse@lysator.liu.se wrote:
Maamoun TK maamoun.tk@googlemail.com writes:
The change looks sensible. One note on the manual wording: it may be worth being explicit that this root check is a best-effort guard against accidental corruption and bugs, not a defense against deliberate fault attacks.
Hence the "(although not all kinds of corruption is detected)". It's hard to make promises about fault attacks.
But to expand a bit on this: Each of public and private key includes a random "seed" used to produce the random values populating the merkle trees. In addition the private key includes a "prf" for randomizing the message, and the public key includes the merkle tree root. My understanding is that any corruption that affects the computation of the message randomization only will go undetected (e.g., consider a hypothetical fault attacks that replaces the prf value with all zeros). I don't see attacks that leak information about the prf itself, and thereby predicting the randomization of future messages, but there might be some.
Faults introduced later during the signature process could trigger, e.g., violations of the one-time-ness of the underlying "wots" signatures. I initially thought that any fault would be highly likely affect the top-level root hash, but that seems wrong: a fault that modifies the *input* to one of the wots signatures could produce a valid wots signature (on the wrong data), and leak information about the secrets for that wots instance, without that being detected via the top-level root hash.
I'll see if I can clarify the wording. Applications that want a bit stronger protection against fault attacks could make an exlicit call to verify the produced signature; then a successful attack will require the attacker to introduce consistent faults to both the signing and the verify operation.
Agreed, and the reason the cheap root check can't catch a faulted WOTS input is neat: the WOTS public key (hence the leaf and root) depends only on the secret seed, not on the value signed, so a wrong-input signature still recomputes to the right root. Full verify catches it, as you say.
Take my read with a grain of salt though, SLH-DSA hasn't been my focus lately; I've been heads-down in ML-DSA, and more recently on some GF(2^128) witness-generation work, so my hash-based-sig intuition is rusty and you are the better authority on the corner cases.
Tangentially, on that GF(2^128) work: the implementation's done but the manual I wrote up for it could use a second pair of eyes. Happy to send it your way if you'd have any interest, no worries at all if not.
Regards, /Niels
-- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.