> On Sep 7, 2018, at 12:08 PM, Adam Petcher <adam.petc...@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.petc...@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
>>>
>
