Conceptual feedback on new ECC JEP

[Anthony Scarpino]

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