Conceptual feedback on new ECC JEP

[Adam Petcher]

I received quite a bit of feedback that questions the value of the new 
provider, and the "branchless mode" in general. At the same time, nobody 
has told me that this mode would be useful to them. So I am removing it 
from the JEP. In short, I will only be doing the second bullet point 
from my last email below---SunEC will be modified to include modern 
implementations of these three curves. I want to stress that no change 
to the spec/description of SunEC will be made. In particular, the "EC" 
algorithms in SunEC will make no guarantees related to security against 
side-channel attacks.

Because this is now an implementation-only change, and there is no new 
feature to document, there is no longer any need to make this change 
under a JEP. My plan is to continue this work under JDK-8208698[1] and 
withdraw the JEP. There is no API or behavior change, so there will be 
no CSR for this change.

[1] https://bugs.openjdk.java.net/browse/JDK-8208698


On 9/25/2018 10: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
>>
>