On 9/10/2018 1:23 PM, Adam Petcher wrote:
The paper[1] containing the proposed formulas is referenced in the JEP.
Thanks!
As far as I know, they are not part of any standard. If you know of any
standardized, complete EC point arithmetic formulas, then let me know.
I don't know, either.
I think it is okay to use these formulas as long as they produce the
same result as the operations in Section 2.2 of SEC 1[2].
The motivation of the JEP is that some formulas may be more easier to
expose attacks. It's true that the formulas impact the security level
of the implementation. I was just wondering if the JEP proposed
formulas have been well analyze. A standard or formal recommendation
may indicate the good quality of the formulas.
It's a concern to me that interoperability is listed as "non-goals". In
general, it may introduce a lot of problems in the current JCE
framework. I don't know your detailed design yet, and not sure if you
are able to mitigate the impact.
Looks like the debate was mainly about the BigInteger. If the keys are
used in the same provider, I don't think the BigInteger is a problem as
you can extend a private BigInteger that you like. If the keys are use
between two providers, add a thine clue to export/import BigInteger may
be worthy for provider interoperability.
I'm a little bit nervous about the two providers design. It simplify
the initial crypto implementation, but left the complexity to developers
and sustaining. I don't have a good sense about how to use them in
JSSE. What if the proposed formulas is vulnerable in the future?
If you believe it is a better one, please consider to replace the
current EC implementation. I know it may only support
secp256r1/secp384r1/secp521r1 now, but we can use it to replace the
implementation of the three curves for now.
Thanks,
Xuelei
[1] https://eprint.iacr.org/2015/1060.pdf
[2] http://www.secg.org/sec1-v2.pdf
On 9/10/2018 2:23 PM, Xuelei Fan wrote:
Can I have the links to the new formulas that you will be used? Are
they part of any current standards?
Thanks,
Xuelei
On 8/23/2018 10:50 AM, 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
