Re: ECC Curves

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.

Cheers,
--Richard

[1] http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-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 14:01:27 UTC