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

Conrado P. L. GouvĂȘa conradoplg at gmail.com
Thu Jan 30 05:13:30 PST 2020

On Tue, Jan 28, 2020 at 12:38 PM D. J. Bernstein <djb at cr.yp.to> wrote:
> Note that the standard definition of signing uses a secret key to sign a
> message. Verification has a different input, the public key, which in
> the fault scenario acts as a double-check on the signing process. The
> public key is _not_ a separate input to signing.
> Internally, EdDSA implementations normally include a cached copy of the
> public key A inside the secret key. When you talk about signing with a
> "mismatched" public key A, you seem to be alluding to some API that, in
> violation of the standard definition of signing, takes A as a separate
> signing input.
> (I must admit to some puzzlement as to how this happens. Surely anyone
> designing a cryptographic API understands the standard concept of a
> signature system, so there must be some _reason_ for violating the
> concept, but I've been unable to find documentation explaining this
> reason. For comparison, the smaller tweak of using _signed messages_
> rather than _signatures_ directly addresses the well-documented "use the
> message without noticing it's a forgery" error pattern.)

Everything is obvious in hindsight. Maybe the public key was not
considered a separate input to signing because the public key wasn't
needed in ECDSA signing. But EdDSA signing needs the public key, so
it's obviously an input to the signing procedure?

I just did an API like that receives the public key as a parameter,
but maybe I'm just dumb. (Now I'll have to settle for a big warning in
the documentation...)

Isn't the whole point of EdDSA to make it less likely for implementers
to get things wrong? Greg's suggestion would contribute to that.


More information about the Curves mailing list