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

[Conrado P. L. Gouvêa]

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.


Conrado