W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > January 2013

Re: ECC Curves

From: David McGrew (mcgrew) <mcgrew@cisco.com>
Date: Tue, 29 Jan 2013 14:52:48 +0000
To: Richard Barnes <rbarnes@bbn.com>, Björn Kinscher <bjoern.kinscher@googlemail.com>
CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183CA012@xmb-rcd-x04.cisco.com>

On 1/29/13 9:00 AM, "Richard Barnes" <rbarnes@bbn.com> 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.

+1

David

>
>Cheers,
>--Richard
>
>[1] 
>http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-para
>meters-8
>[2] http://tools.ietf.org/html/rfc4492
>
>
>
>
>On Jan 29, 2013, at 5:07 AM, Björn Kinscher
><bjoern.kinscher@googlemail.com> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 January 2013 15:01:45 GMT