LoupVaillant
commented
4 years ago Perfect, thanks! Merging right away
Closed fscoto closed 4 years ago
LoupVaillant
commented
4 years ago Perfect, thanks! Merging right away
While already there, add a very sternly worded warning about omitting the first pass that will appear to work but will, in fact, just repeat the Sony PlayStation 3 ECDSA nonce disaster with EdDSA instead.
RFC 8032 § 8.7 already hates Monocypher's guts for providing this risky interface at all, so we might as well use it for good: By showing how it can be used to mitigate power analysis attacks.
The wording is such that crypto_sign.3monocypher redirects to crypto_sign_init_first_pass.3monocypher for how to mitigate power-related side channels; crypto_ed25519_sign_init_first_pass.3monocypher already points to crypto_sign_init_first_pass.3monocypher wholesale anyway.
I've intentionally broken the rule that crypto_sign_init_first_pass.3monocypher only talks about BLAKE2b in this specific instance because of the redirect on the Ed25519 page so that this content doesn't need to be duplicated. There's no issue doing this with the example code because both hash functions call their internal compression functions.
While I could've just described what to do, I'd feel uneasy leaving implementers just guessing what it is that we mean and overshoot or undershoot by 32 bytes (undershooting being particularly fatal) or just be too scared to try at all, so I've added example code nonetheless. It's been adorned with the bare minimum of an explanation about the magic number
128-32. Ideally, I'd have a good place to go on at length about EdDSA nonces, but there really isn't.On the other hand, I have very much intentionally omitted the fact that you could be okay just hashing a random nonce in (which then should be preferably at least 32 bytes, though you might be able to get away with less as well, I don't think there's a well-defined threshold for randomness with hash->reduce) or other kinds of nonces in the first pass of EdDSA in particular. While this is interesting and sometimes very much useful knowledge, it's also a large footgun and the whole reason why RFC 8032 § 8.7 recommends against init-update-final interfaces in APIs (unless using Ed25519ph, but that means you need a collision-resistant hash function as the prehash, losing the security benefits of not requiring collision resistance from the hash function in EdDSA in the first place).