Conceptual feedback on new ECC JEP

[Xuelei Fan]

I did not follow the discussion.  But it does not sound right to me to 
have an application to be provider dependent (#3).

I was not confident that a new provider instead of updating the existing 
provider is a good idea.  It might be a significant effort to update 
existing provider.  However, if we don't do that, the cost to use the 
new provider is not minimal.

As we discussed previous, lacking interop could face significant issues 
and result in complicated coding in practice.  Thinking about SunPKCS11 
and SunMSCAPI provider, and how many trouble we have had for them, and 
how many workaround we have patched for them.

Unless it is not possible to have an interop-able implementation, I 
would suggest take more time to have an interop-able design and impl.

Is it possible to have an interop-able impl?  If it is possible, how 
much effort will it take?

Thanks,
Xuelei

On 9/25/2018 7:40 AM, Adam Petcher wrote:
> 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
>>
>