Thanks, everyone for your feedback on this JEP. I have incorporated this
feedback (received on this mailing list and elsewhere) into the draft
JEP[1]. Here is a summary of the current JEP and plan:
*) A new provider (name TBD) will be developed to hold the new ECC
implementation for the three curves. This provider will feature the
interoperability-limiting restrictions on its API that were discussed at
length on this mailing list. The new provider will be at the end of the
list, so it won't be used by default.
*) The operations of the new implementation will also be added to SunEC
for the three curves. This means that the new implementation will be
used by default, in a completely compatible way (without any
restrictions on its API). Using the new implementation through SunEC
will not provide the same level of security against side-channel attacks
as using it through the new provider.
*) We will add some tests that make sure that TLS still work when the
new provider is used instead of SunEC. We may need to make some small
changes to the TLS implementation in order to get these tests to pass.
*) A couple of people asked me about whether we could modernize the
implementation of more curves in the future. I added a section at the
end of the JEP to discuss this.
Of course, none of this is set in stone, and we still have some API
details to work out in the CSR. I'll be doing the CSR next, and I'm
happy to accept feedback at any time.
[1] https://bugs.openjdk.java.net/browse/JDK-8204574
On 8/23/2018 1:50 PM, Adam Petcher wrote:
I'm starting work on yet another ECC JEP[1], this time with the goal
of developing improved implementations of existing algorithms, rather
than implementing new ones. The JEP will re-implement ECDH and ECDSA
for the 256-, 384-, and 521-bit NIST prime curves. The new
implementation will be all Java, and will resist side-channel attacks
by not branching on secrets. It will go in a new provider which is not
in the provider list in the java.security file by default. So it will
need to be manually enabled by changing the configuration or putting
the new provider name in the code. It will only support a subset of
the API that is supported by the implementation in SunEC. In
particular, it will reject any private keys with scalar values
specified using BigInteger (as in ECPrivateKeySpec), and its private
keys will not return scalar values as BigInteger (as in
ECPrivateKey.getS()).
Please take a look and send me any feedback you have. I'm especially
looking for suggestions on how this new implementation should fit into
the API. I would prefer to have it enabled by default, but I can't
think of a way to do that without either branching on secrets in some
cases (converting a BigInteger private key to an array) or breaking
compatibility (throwing an exception when it gets a BigInteger private
key).
[1] https://bugs.openjdk.java.net/browse/JDK-8204574
