I received quite a bit of feedback that questions the value of the new
provider, and the "branchless mode" in general. At the same time, nobody
has told me that this mode would be useful to them. So I am removing it
from the JEP. In short, I will only be doing the second bullet point
from my last email below---SunEC will be modified to include modern
implementations of these three curves. I want to stress that no change
to the spec/description of SunEC will be made. In particular, the "EC"
algorithms in SunEC will make no guarantees related to security against
side-channel attacks.
Because this is now an implementation-only change, and there is no new
feature to document, there is no longer any need to make this change
under a JEP. My plan is to continue this work under JDK-8208698[1] and
withdraw the JEP. There is no API or behavior change, so there will be
no CSR for this change.
[1] https://bugs.openjdk.java.net/browse/JDK-8208698
On 9/25/2018 10:40 AM, Adam Petcher wrote:
Thanks, everyone for your feedback on this JEP. I have incorporated
this feedback (received on this mailing list and elsewhere) into the
draft JEP[1]. Here is a summary of the current JEP and plan:
*) A new provider (name TBD) will be developed to hold the new ECC
implementation for the three curves. This provider will feature the
interoperability-limiting restrictions on its API that were discussed
at length on this mailing list. The new provider will be at the end of
the list, so it won't be used by default.
*) The operations of the new implementation will also be added to
SunEC for the three curves. This means that the new implementation
will be used by default, in a completely compatible way (without any
restrictions on its API). Using the new implementation through SunEC
will not provide the same level of security against side-channel
attacks as using it through the new provider.
*) We will add some tests that make sure that TLS still work when the
new provider is used instead of SunEC. We may need to make some small
changes to the TLS implementation in order to get these tests to pass.
*) A couple of people asked me about whether we could modernize the
implementation of more curves in the future. I added a section at the
end of the JEP to discuss this.
Of course, none of this is set in stone, and we still have some API
details to work out in the CSR. I'll be doing the CSR next, and I'm
happy to accept feedback at any time.
[1] https://bugs.openjdk.java.net/browse/JDK-8204574
On 8/23/2018 1:50 PM, Adam Petcher 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
