bip-schnorr: exactly defined is an advantage over ECDSA in a similar way that non-malleability is
gmaxwell opened this issue · 4 comments
Traditional implementations of ECDSA do not guarantee that any signature which will be accepted by any arguably correct implementation will be accepted by any other arguably correct implementation. This can be fixed by adding additional requirements like how bitcoin does with LowS.
This property adds extra considerations to BIP-schnorr since it also seeks to make sure batch verification returns consistent results with scalar verification.
It might be worth mentioning that this was an explicit design criteria. (and if someone found an exception, it would be a serious flaw in the proposal)
Edit to be clear, it should say something like "Every input string is consistently rejected or consistently accepted by all conforming implementations, regardless of how the input string was constructed."
Traditional implementations of ECDSA do not guarantee that any signature which will be accepted by any arguably correct implementation will be accepted by any other arguably correct implementation.
You mean due to !&!*#&^ DER encoding of signatures? Or other edge cases?
This property adds extra considerations to BIP-schnorr since it also seeks to make sure batch verification returns consistent results with scalar verification.
That's a great thing to point out: not only do we aim to make sure that every compliant signing algorithm results in a signature that is accepted by every compliant verifier, we also aim to make sure that all compliant verifiers will agree about validity of non-compliant signers.
You mean due to !&!*#&^ DER encoding of signatures? Or other edge cases?
DER is an obvious example that hits basically every ECDSA implementation I've seen. I mentioned to you the other day that X9.62 states checking hybrid consistency is optional. I wouldn't be too surprised to see other corner cases.
I think the objective of this specification is that every input string is consistently rejected or accepted by all conforming implementations, regardless of how the input string was constructed. This is not an objective that normally shows up for other signature systems, instead they just want the weaker property of "signatures constructed with the specified procedure will be accepted and someone who doesn't know the private key can not construct an accepted string".
This stuff isn't unique to ECDSA. E.g. Ed25519 implementations differer on if "0" (point at infinity) is an acceptable public key (with secret key 0), they also differ on if s in the signature has to be less than the subgroup order, less than 2^253, or less than 2^254. A collection of signatures can partition ed25519 verifiers into at least six groups based on those properties, and there are actual implementations of at least several of them.
orfeas on IRC points out that the reference to BIP-66 should be attached to this property, not malleability (which should cite BIP62 only probably, 66 did address malleability but the BIP doesn't discuss it).