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 <[email protected]>
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
