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.
Regards, /Niels