Inline below.
On 11/6/2018 2:18 AM, Weijun Wang wrote:
On Nov 6, 2018, at 1:06 PM, Xuelei Fan <xuelei....@oracle.com> wrote:
On 11/5/2018 8:37 PM, Weijun Wang wrote:
On Nov 6, 2018, at 12:12 PM, Xuelei Fan <xuelei....@oracle.com> wrote:
On 11/5/2018 7:13 PM, Weijun Wang wrote:
Please take a review at the CSR at
https://bugs.openjdk.java.net/browse/JDK-8213401
As for implementation, I intend to report an error when -keyalg is not EC but
-curvename is provided. If both -curvename and -keysize are provided, I intend
to ignore -keysize no matter if they match or not.
Why not use a strict mode: fail if not match. It might be misleading if
ignoring unmatched options.
We can do that, but misleading to what? That we treat -curvename and -keysize
the same important?
If the option "-keysize 256 -curvename sect163k1" work, I may think that the
key size if 256 bits. I want to create a 256 bits sect163k1 EC key, and the tool allows
this behavior, so I should get a 256 bits sect163k1 EC key. Sure, that's incorrect, but
I don't know it is incorrect as the tool ignore the key size. What's the problem of the
command, I don't know either unless I clearly understand sect163k1 is not 256 bits. The
next question to me, what's the key size actually is? 256 bits or 163 bits? which
option are used? It adds more confusing to me.
Well explained. I've updated the CSR and this will be an error.
Sorry to drop in late.
Basically, for EC private keys - either binary or prime curves, you will
reduce whatever initial random value you generate mod n of the curve to
get the final private key. The generation logic should take care of
this. You could use key size as a way of controlling how many extra
bits are generated(see FIPS 186-4, section B.4.1) and error only if key
size was less than the size of the curve's n.
So 1) generate a random value of keysize length or if not specified the
length of the N of the curve plus 64, 2) reduce mod N.
Mime.
We can ignore the -keysize option, but it is complicated to me to use the tool.
Another question: in sun.security.util.CurveDB, we have
// Return EC parameters for the specified field size. If there are known
// NIST recommended parameters for the given length, they are returned.
// Otherwise, if there are multiple matches for the given size, an
// arbitrary one is returns.
// If no parameters are known, the method returns null.
// NOTE that this method returns both prime and binary curves.
static NamedCurve lookup(int length) {
return lengthMap.get(length);
}
FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do
we have a choice?
In fact, CurveDB.java seems to have a bug when adding the curves:
add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,...
add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default?
add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,...
add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,...
and now 163 is sect163r2 and 233 is sect233k1.
I assume we should always prefer the K- one?
TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves.
There is no ambiguity for prime curves.
Do you mean if no -curvename option, there is a need to choose a named curve?
ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I
just meant if we have a bug here and if we should be more public on what curve
is chosen.
I see your concerns.
It might be a potential issue if we use a named curve if no curvename
specified. If the compatibility is not serious, I may suggest supported named
curves only, or use arbitrary curves but with a warning.
If people only want prime curves then -keysize still works. A warning is enough since in
the CSR I've also said "we recommend".
Thanks
Max
Xuelei
