[curves] Ed25519 / EdDSA key leakage due to fragility in recommended nonce procedure

[Trevor Perrin]

On Mon, Jan 27, 2020 at 10:49 PM Greg Maxwell <gmaxwell at 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