RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1, n-1] for SunEC provider

[Jamil Nimeh]

On Wed, 1 Sep 2021 15:13:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> So the key is only validated before it's used? Why not when creating it?
> 
> Do we need to validate public key as well? It might not be a problem since modular calculation should scale it back to normal. Our old native impl does have one at https://github.com/openjdk/jdk11u-dev/blob/master/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c#L481.
> 
> One more thing: I would prefer `[1, n)` or `(0, n)` in the bug title, and, it's probably more efficient to call `sVal.compareTo(BigInteger.ZERO) <= 0` than `sVal.compareTo(BigInteger.ONE) < 0`.

Good questions.
WRT the KeyFactory, I looked not only at ours but also BC's and neither seems to put restrictions on ranges for an ECPrivateKey.  Given that behavior I thought for this change I'd leave KeyFactory alone.

Validating the public key might not be a bad idea.  I could come up with a Java-based version of what's in libsunec and update the test to cover that as well.

With respect to the synopsis, I'd prefer to leave it [1, n-1] because that's the notation used by FIPS 186-4, X9.62 and SEC 1.  But the BigInteger.compareTo I will change as you suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5324