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
