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.petc...@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 >
