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.
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