I don't think there is any current AlgorithmParameterSpec that allow this for a KeyPairGenerator. When a curve name is used, keysize is calculated from the field size.
--Max > On Nov 7, 2018, at 4:05 PM, Michael StJohns <mstjo...@comcast.net> wrote: > > 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
