Test against jdk.security.useLegacyECC

[yschimke]

We may need to test against jdk.security.useLegacyECC in both modes to have full JDK coverage.

Context: https://www.oracle.com/technetwork/java/javase/8u221-relnotes-5480116.html, experimental off by default new implementation of ECC?

https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009840.html

[yschimke]

Related security advisory
https://nvd.nist.gov/vuln/detail/CVE-2019-2745

https://www.waratek.com/oracle-july-2019-cpu/

This quarter’s Java SE update comes with an improved implementation of the Elliptic-curve cryptography (ECC) which also offers greater resiliency against side-channel attacks CVE-2019-2745. However, note that the new ECC implementation is disabled by default and the system property jdk.security.useLegacyECC, has been introduced that enables switching between implementations of ECC.

[yschimke]

Closing without fix, as its off by default, not clear it's meaningfully our problem, and may be further revised.

[nedtwigg]

Just wanted to note this for others who might bump into this:

• 8u221 useLegacyECC is true by default
• 8u231 useLegacyECC is false by default

How this manifested for me is that unit tests which asserted on SHA512withECDSA values (using a deterministic RNG) changed for no apparent reason between 8u171 and 8u232, and it took a good bit of hunting to figure out why. It seems that if you generate a signature from either version, it will be accepted in either version, so it doesn't seem to be a problem. But if you encounter this, that's what happened.