On Mon, Jan 27, 2020 at 10:49 PM Greg Maxwell <gmaxw...@gmail.com> wrote: > > The nonce generation function input should be a strict superset of the > arguments into the challenge hash (except for R, of course)
I agree that's a good robustness principle, the "Generalizing EdDSA" post followed that logic though didn't state it so clearly. > This is also related to a general (and I think less serious) weakness > with RFC6979 and other similar schemes where there is commonly no > commitment to either the group, its generator, or the "signature > scheme" the nonce is being used with. If someone can get me to sign > the same message with the same key using both ECDSA and schnorr or > using the same signature scheme and two distinct generators (generator > is an implicit input to the schnorr challenge hash via the R value), > the lack of these inputs into the nonce function causes the signatures > to leak my key. Fortunately, reusing private keys in different > cryptosystems is already a widely discouraged practice (and no one > ever engages in any widely discouraged practices, right???)... > > For many hash functions (including all Merkle–Damgård style ones) > inclusion of system parameters like algorithms or generators can be > made runtime-costless by caching hash-function midstates if care is > taken to pad values out to compression function boundaries. I suppose that's a reasonable precaution. Some time I'll write a sequel to the "Generalizing EdDSA" post that generalizes further and tries to fold in more of these emerging "best practices". Trevor _______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves