On Tue, Jan 28, 2020 at 12:38 PM D. J. Bernstein <d...@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 _______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves
