Re: [TLS] Using ECC Brainpool curves with TLS

[Johannes Merkle <[e-mail]>]

Douglas,

>> [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one
>> being the "quadratic twist" of the other having the same algebraic structure (and hence, security level), but one of
>> them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the
>> implementation we propose to register IANA values (for EC Named Curve) for both curves for each bit length. Of course,
>> this doubles the number of number assignments. Does anyone consider this a problem?
> 
> One alternative would be to use an extension, similar to the Supported Points Format Extension, to indicate whether to use the twisted form or the original form.  Or in fact define the twisted form as just another ECPointFormat.
> 
An extension would work, but although these curves are isomorphic (mathematically equivalent), there parameters and
arithmetic are different. So my feeling is that they should not be assigned to the same curve values.

A point format is even less suitable as this has nothing to do with EC point representation.

We have approx 65000 assignments left. So the question is if saving 7 numbers is worth defining extra syntax and
semantics. My personal opinion is that it is not.

> But you could also ask the question: if the quadratic twist is more efficient, will anyone ever use the untwisted version?  If not, then perhaps you could just standardize the twisted version alone, reducing the number of combinations to be tested and supported.

The reason why some people might prefer the "normal" curves is that for these it is easier to avoid patents. This is
always a big issue with ECC. While the Brainpool curves avoid special primes to facilitate patent-free implementations,
we still wanted to leave the implementors a choice between "fast" and "slower but more patent-safe" by introducing the
quadratic twist.


Johannes
--
Johannes Merkle
secunet Security Networks AG
[e-mail]
www.secunet.com