Conceptual feedback on new ECC JEP

[Xuelei Fan]

Hi,

I have not had a chance to review this JEP yet.  Personally, if 
possible, I would expect there is no public APIs update so that more 
applications can benefit from the enhancement, and SunJSSE could 
benefits from more crypto providers.   I'm not sure if it is possible or 
not now, or how could we minimize the APIs update.  I will see if I 
could be here next week.  Please go ahead if you have an agreement 
before I look into this JEP.

Thanks,
Xuelei

On 9/7/2018 12:08 PM, Adam Petcher wrote:
> This is a good suggestion. I don't have particularly strong feelings 
> about using separate providers vs a property in a single provider. I 
> think the fundamental issues are the same, and this choice mostly 
> affects API details.
> 
> Do you think this should be a system property, security property, or 
> something else? Should it be modifiable at any time? Perhaps it has to 
> be in order to address Mike's desire to put the provider in 
> "import/export mode". Would the property affect existing keys? Again, I 
> think it would have to, so you can generate a key, turn off branchless 
> mode, and then export it. What about curves other than P256, P384, and 
> P521? We can't do branchless operations in those curves, so any attempt 
> to use them when this property is enabled would result in an exception.
> 
> The questions above are for everybody, if you have thoughts on any of 
> this, please share. My initial thoughts are that using a property may 
> give us some additional flexibility, and may improve the interface, but 
> the main cost is additional complexity in the implementation, since 
> we'll need to implement some checks that would otherwise be accomplished 
> by provider selection and having separate code.
> 
> On 9/7/2018 1:53 PM, Anthony Scarpino wrote:
>> Adam,
>>
>> I tend to agree with Mike that disallowing import/export of keys using 
>> BigInteger is not the value of a branchless implementation.  As you 
>> point out in the JEP the provider is greatly hindered by this design 
>> choice. I feel it would be better to implementing the BigInteger parts 
>> and have a property to shut them off for a pure branchless 
>> implementation.  That should allow the provider to be used in the 
>> default provider list and the ‘opt-in’ would be the property to turn 
>> off BigInteger or any other branching situation.  I am concerned the 
>> desire for a purest provider will result in it being unused.  
>> Documentation can be clear about the import/export situation, the 
>> preference toward PKCS8EncodedKeySpec, and the property to lock it down.
>>
>> Tony
>>
>>> On Aug 23, 2018, at 10:50 AM, Adam Petcher <adam.petcher at oracle.com> 
>>> 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
>>>
>