Conceptual feedback on new ECC JEP

[Adam Petcher]

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