Conceptual feedback on new ECC JEP

[Adam Petcher]

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
>