RFR 8208698: Improved ECC Implementation

[Anthony Scarpino]

On 11/30/18 12:01 PM, Adam Petcher wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8208698
> webrev: http://cr.openjdk.java.net/~apetcher/8208698/webrev.00/
> 
> This is a re-implementation of ECDH and ECDSA that is designed to be 
> resilient against side-channel attacks. The implementation only supports 
> the 256-bit, 384-bit, and 521-bit NIST curves, and only key pair 
> generation, key agreement, and signature is implemented. For other 
> curves/algorithms, the existing native ECC implementation will be used. 
> This change depends on a separate change (reviewed concurrently) that 
> enhances the finite field arithmetic library. The implementation is 
> intended to follow the recommendations in FIPS 186-4 and SP 800-56A. 
> More information on the techniques used can be found in the JBS ticket.
> 
> There is no new signature verification implementation, because signature 
> verification typically does not involve secret inputs. If anyone has any 
> desire for branchless signature verification, please let me know.
> 
> I tested this change by running all the existing regression tests, and 
> by checking it against some additional test vectors. I've done some 
> initial benchmarking on two platforms: a Linux VM with a Skylake CPU, 
> and a Macbook with a Haswell CPU. In general, the performance of the new 
> implementation is 20-30% faster than the existing native implementation. 
> Though the performance of the 521-bit curve is actually around 10% 
> slower on Mac/Haswell. I think this regression is acceptable, because 
> the 521-bit curve is not used as much as the others, and it is only used 
> if lower performance is acceptable. I plan to do some additional 
> benchmarking while the review is in progress.
> 
> This change includes a new (internal) class hierarchy for EC points in 
> various coordinate systems. It may seem a little over-complicated, since 
> the only type of point used in the implementation (other than affine) is 
> ProjectivePoint. But it is common for different curves to use different 
> coordinate systems, even within the same ECC algorithm/implementation. 
> The EdDSA prototype also uses these point classes, and it uses extended 
> homogeneous coordinates, in addition to projective coordinates.
> 

I don't have any code comments to add to your code. It's pretty clean 
and mostly algorithm code which the known answer tests will do a better 
job of judging correctness.

One comment I did have was if there were any implications from using 
little endian on sparcv9?  This code will never interact with the native 
ECC code on big endian processors?  Did you/can you run sparcv9 
regressions tests?

Tony