Welp. It’s the crypto bug of the year. Mark it down for April. Java 15-18 ECDSA doesn’t sanity check that the random x coordinate and signature proof are nonzero; a (0,0) signature validates any message. Breaks JWT, SAML, &c. neilmadden.blog/2022/04/19/p…
These are my very most favorite crypto bugs and are endemic to asymmetric primitives (similar things happen in SRP and DH).
I’ll take a shot at this and see how wrong I can be in a couple tweets. An ECDSA sig is (r,s). r is a random value derived (infamously) from a nonce k. s is a signature proof mixing r, a hash, and the private key, divided by k.
ECDSA verification uses the pubkey and the hash to extract r’ from s and then checks to make sure r’ matches r. If they’re both zero… there’s not much to check!
The broader issue here isn’t that Java 15+ rewrote their C++ ECDSA in pure Java and broke it, though that’s an issue (see: Wycheproof for more). It’s that people use ECDSA in things like JWT without extremely compelling reasons to.
Just a basic cryptographic risk management principle that cryptography people get mad at me for saying (because it’s true) is: don’t use asymmetric cryptography unless you absolutely need it.
It is nevertheless funny that there is a Wycheproof test for this bug (of course there is, it’s the most basic implementation check in ECDSA) and nobody bothered to run it against one of the most important ECDSA’s until now.

Apr 20, 2022 · 12:38 AM UTC

but like, that’s WHY you shouldn’t use asymmetric cryptography unless you absolutely need it, because you have to assume nothing like Wycheproof ran against your implementation; I shit you not people have claimed to verify implementations by having them pass spec test vectors.
Replying to @tqbf
TIL about Wycheproof! This is sort of poignantly ironic given the background of the name at the top of the readme.