wycheproof

the code's speed compared to a naive ladder). Unfortunately, doing that introduces edge cases that weren't there before, that cause the point we get back to be invalid. So invalid in fact that adding it to another point gives us zero half the time or so, causing the verification to succeed even though it should have failed! (Pro tip: don't bother with that conversion, variable time double scalarmult https://loup-vaillant.fr/tutorials/fast-scalarmult is even faster.) A pretty subtle error, though with eerily similar consequences. It looked like a beginner-nuclear-boyscout error, but my only negligence there was messing with maths I only partially understood. (A pretty big no-no, but I have learned my lesson since.) Now if someone could contact the Whycheproof team and get them to fix their front page so people know they have EdDSA test vectors, that would be great. https://github.com/google/wycheproof/pull/79 If I had known about those, the whole debacle could have been avoided. Heck, I bet my hat their ECDSA test vectors could have avoided the present Java vulnerability. They need to be advertised better.

simplify those protocols, making them easier to audit. [1]: https://loup-vaillant.fr/tutorials/cofactor > Recently, we also uncovered a critical vulnerability in a number of open-source ECDSA libraries, in which the verification function failed to check that the signature was non-zero, allowing attackers to forge signatures on arbitrary messages Oh. That explains a lot. See, I made one significant mistake in all my time as a cryptographic implementer². The effect was, all-zero signatures were accepted half the time, with any public key. Sounds familiar? In any case, some people were quick to assume I was a drooling incompetent for failing to perform such a basic check as rejecting the all-zero signature. If I was implementing ECDSA, they’d have been right. Except I was implementing EdDSA, which already rejects all-zero signatures with its main algorithm. An explicit all-zero check is not needed at all. DJB himself for instance omits it in TweetNaCl. My bug was more subtle: I didn’t fail to check a standard edge case any decent specification would mention. I introduced an edge case by doing a less-than-safe conversion with a less-than-perfect understanding of the maths involved. (To those who wonder why I even tried, I asked around before attempting this, and no one warned me—cryptographers are busy. And to those who are wondering why I didn’t check with Whycheproof from the beginning, that’s because I looked at their list of supported protocols, and didn’t found EdDSA. To this day, their GitHub main page lists neither EdDSA nor Ed25519, despite my pull request from nearly 2 years ago.³ If someone from Google hears this, please…) In any case, I now understand the mockery better. Those people likely pattern matched my vulnerability with the corresponding ECDSA beginner error, and shot me down without checking what was actually going on. I guess they too were busy. [2]: https://monocypher.org/quality-assurance/disclosures [3]: https://github.com/google/wycheproof/pull/79

e calling this a malleability issue. Malleability is about taking a triple (public key, signature message) and tweaking bits to produce another valid triple. >We can add a low order point to A, and subtract it from R. That way we produce a valid signature, but from a public key nobody vouches for. If the verifier checks the weaker equation, we can add a low order point to just R, and produce a "valid" signature with the same public key. This is the second time I saw this claim. When I first saw it [2], I thought, wait, this test is missing in Wycheproof [3], but Bleichenbacher does NOT miss anything. That's when I knew it's wrong. Modifying A or R instantly makes the signature invalid. Using the article's notation, the signature is validated by checking that B.s.8 == R.8 + A.h.8, where h = SHA-512(R, A, M) and M is the message Multiplying the cofactor or not doesn't matter, doesn't introduce any weakness, as implied by the article. If R or A is changed, h will change. [1] https://github.com/google/tink [2] https://github.com/dalek-cryptography/ed25519-dalek/issues/2... [3] https://github.com/google/wycheproof. Wycheproof has tests for EdDSA malleability, but it only tests if s is not properly range checked.

>

lking about, but I know of no similar projects for other domains. In any case, what I seek is even simpler: an indexed repository of CSV data files mapping input to output As a start, how about we start an open Github project to collect together and unlock standard test cases that HN developers have buried in their projects?