Conceptual feedback on new ECC JEP

[Adam Petcher]

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