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