Conceptual feedback on new ECC JEP

[Anthony Scarpino]

> On Sep 7, 2018, at 12:08 PM, Adam Petcher <adam.petcher at oracle.com> 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?

I would say a security property

> 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.

My thought was the property would allow the branchless import/export for that java instance.   Not turning it on and off during operations.  I think the value of the branchless operation is in the usage of the algorithms. If an app wants to use a pure branchless provider the property can be set or never use the APIs with BigInteger in them.

One could avoid the property completely by just documenting clearly the interfaces that branched and then leave it to the app developer, but from the email discussion with Mike it sounded like you preferred strong controls on the provider. 

> 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.

I wasn’t going to propose anything further than your existing curves, but it would be nice if branchful curves could be added to eventual replace SunEC.  I know that isn’t the intent of this JEP and depends if you want to expand it.

> 
> 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.

A branchless and branchful provider is also an fine idea. You’d know better on the code impact between two providers vs a property. A branchful class extending the branchless class may create the seperation your looking for. 

Tony

> 
>> 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
>>> 
>