Java versions 15, 16, 17, and 18 (and maybe some older versions) have a big problem, ECDSA signature verification is totally broken. The story is a prime example of the dangers of unintended consequences, the pitfall of rolling your own crypto, and why to build a test suite for important code. In Java 15, the ECDSA verification code was re-written, moving the code from C++ to a Java-native implementation. The new code misses an important check, that the initialization and proof values are both non-zero.
A refresher on ECDSA will likely help. The Elliptic Curve Digital Signature Algorithm is a asymmetric cryptography scheme, where a public-private keypair is used to encrypt or sign messages. Rather than using the using factorization of large numbers as the one-way function, ECDSA uses a vector bouncing around the inside of a special elliptic curve. A signature consists of two values, the random starting point r, and the proof s. Part of the ECDSA spec is that those can’t be zero, because the verification function includes multiplication by those values. Multiplication and division by zero has a tendency to short-circuit algorithms, and this one is no exception. A signature of r=0 and s=0 is always valid, no private key needed.
The Java code left out the sanity-check for zeroes in the signature, so any Java program using ECDSA signatures can be defeated with trivial fake credentials — all zeroes. The worst part of this flaw is that it’s a known problem, and included in published test cases like Wycheproof. This wasn’t a project I was familiar with, but it’s definitely on my cryptog ..
Support the originator by clicking the read the rest link below.
