RFR CSR for 8213400: Support choosing curve name in keytool keypair generation

Weijun Wang weijun.wang at oracle.com
Wed Nov 7 15:08:04 UTC 2018


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 <mstjohns at 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.fan at oracle.com> wrote:
>>> 
>>> On 11/5/2018 8:37 PM, Weijun Wang wrote:
>>>>> On Nov 6, 2018, at 12:12 PM, Xuelei Fan <xuelei.fan at 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




More information about the security-dev mailing list