Conceptual feedback on new ECC JEP

[Roger Riggs]

Hi,

In general, System properties should be avoided, they add complexity to 
configurations and
especially if they change sensitive behavior.  In any case, the defaults 
should be secure-by-default;
not the other way around.

Perhaps two different providers, one secure and one more secure.

$.02, Roger


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