Re: ECC Curves

On 1/29/13 9:00 AM, "Richard Barnes" <> wrote:

>Hi Björn,
>Thanks for your comments on this.
>Unfortunately, I don't think allowing apps to specify curve parameters
>necessarily gets you what you want, unless implementations are required
>by the specification to accept and use any set of parameters.  Otherwise,
>an implementation can say, "These parameters are legal in the syntax, but
>I will not use them", in which case you're back where you started.
>That requirement would be pretty onerous on implementors, for exactly the
>reason you state.  Namely, browsers get their crypto from underlying
>crypto libraries, so if the underlying libraries don't support custom
>curves, then the browser would have to re-implement basically the entire
>EC computation stack.
>I think a safer route would be to have a registry for named curves (or
>re-use one, z.B., [1][2]) with a fairly liberal policy for how curves are
>admitted.  That would at least give crypto library implementors a
>consolidated, finite list of curves to support if they want their library
>to be useful for the web.



>On Jan 29, 2013, at 5:07 AM, Björn Kinscher
><> wrote:
>> Hi,
>> I attended the talk of Harry Halpin at the 29c3, where I heard that
>> there is still a lot of ongoing work on the webcrypto api. I would
>> like to know if it is considered to give api users the possibility of
>> defining their own curves for ECDSA and ECDH.
>> Last year I worked with the new german identity card. It uses recently
>> defined curves, which are not available in any classic encryption
>> libraries. Thus I think it is necessary to enable api users to define
>> their own curves to ensure compatibility with other applications.
>> I do not want api users to create their own curves, but that they are
>> able to use recently approved ones without waiting for user agent
>> vendors to implement them. I know there is a risk of users creating
>> weak ones, but I still think the possibility to define new curves
>> would be very useful. Especially since a user agent can't include all
>> possible useful curves.
>> My suggestion is to extend EcKeyGenParams with something like the
>> following to give api users the possibility to define their custom
>> curves:
>> typedef (namedCurve or customCurve) CurveIdentifier;
>> dictionary customCurve {
>>  // prime number
>>  BigInteger prime;
>>  // a and b are definded by the equatation y^2 = x^3 + a*x + b
>>  BigInteger a;
>>  BigInteger b;
>>  // generator of the group
>>  ECPoint generator;
>>  // order of the group
>>  BigInteger order;
>>  // index of the sub-group
>>  BigInteger cofactor;
>> }
>> dictionary EcKeyGenParams : AlgorithmParameters {
>>  // A named or a custom curve
>>  CurveIdentifier curve;
>> };
>> Another option would be to add an interface to register new named
>> curves with these parameters.
>> Regards
>> Björn Kinscher

Received on Tuesday, 29 January 2013 15:01:45 UTC