Details

Type: Enhancement

Status: Resolved

Priority: P4

Resolution: Fixed

Affects Version/s: 7, 8, 11, 12

Fix Version/s: 12

Component/s: securitylibs

Subcomponent:

Resolved In Build:b24
Backports
Issue  Fix Version  Assignee  Priority  Status  Resolution  Resolved In Build 

JDK8225697  11.0.5  Christoph Langer  P4  Resolved  Fixed  b01 
JDK8217590  11.0.4oracle  Ivan Gerasimov  P4  Resolved  Fixed  b01 
JDK8225500  11.0.4  Christoph Langer  P4  Resolved  Fixed  b07 
JDK8227354  openjdk8u232  Andrew Hughes  P4  Resolved  Fixed  b01 
JDK8226960  openjdk8u222  Andrew Hughes  P4  Resolved  Fixed  b08 
JDK8218251  8u222  Ivan Gerasimov  P4  Resolved  Fixed  master 
JDK8217697  8u221  Ivan Gerasimov  P4  Resolved  Fixed  b01 
JDK8224348  emb8u221  Ivan Gerasimov  P4  Resolved  Fixed  master 
JDK8218786  7u231  Ivan Gerasimov  P4  Resolved  Fixed  b01 
JDK8227884  openjdk7u  Andrew Hughes  P4  Resolved  Fixed  master 
Description
There are two components of the implementation that are mostly independent: the elliptic curve point arithmetic and the finite field arithmetic.
For the EC point arithmetic, a good approach is to use the technique described in "Complete addition formulas for prime order elliptic curves" by Renes, Costello, and Batina. The formulas in this paper are relatively simple and efficient, and they include specializations for a=3 as in the NIST prime curves. The same formulas can be used for all curvesthe only thing that varies is one of the curve coefficients, and the finite field, which will have a different implementation for each curve.
For the finite field arithmetic, we can extend the existing field arithmetic library that was developed for X25519/X448, EdDSA, and Poly1305. The NIST primes have a similar structure to the primes used in these schemes, except they tend to have more terms, and the largest term doesn't have many useful factors. So we can continue to use the approach that was used in the Curve25519 field: use a few extra bits in the representation (e.g. 260 bits for the 256bit field) and shift values around as necessary during reduction. The extra terms cause some extra operations during reduction (compared to more modern fields like in Curve25519), but all coefficients of these terms are +/1, so these extra operations are all additions/subtractions.
This effort will require the implementation of 36 new finite field arithmetic classes, bringing the grand total up to 510 classes. These classes contain handoptimized multiply/carry/reduce functions that maximize the use of primitive values to reduce temporary object allocation. They are somewhat cumbersome to develop, and very difficult to read and understand. A code generator will be used to reduce the development/maintenance burden for all these classes.
Attachments
Issue Links
 backported by

JDK8217590 Improved ECC Implementation
 Resolved

JDK8217697 Improved ECC Implementation
 Resolved

JDK8218251 Improved ECC Implementation
 Resolved

JDK8218786 Improved ECC Implementation
 Resolved

JDK8224348 Improved ECC Implementation
 Resolved

JDK8225500 Improved ECC Implementation
 Resolved

JDK8225697 Improved ECC Implementation
 Resolved

JDK8226960 Improved ECC Implementation
 Resolved

JDK8227354 Improved ECC Implementation
 Resolved

JDK8227884 Improved ECC Implementation
 Resolved
 blocks

JDK8204574 Improved ECC Implementation
 Closed
 is blocked by

JDK8208648 ECC Field Arithmetic Enhancements
 Resolved
 relates to

JDK8226880 Backport of JDK8208698 (Improved ECC Implementation) should not bring parts of JDK8205476 (KeyAgreement#generateSecret is not reset for ECDH based algorithm)
 Resolved