The paper[1] containing the proposed formulas is referenced in the JEP.
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
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].
[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
