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