Re: [Cfrg] revised requirements for new curves

[Manuel Pégourié-Gonnard <[e-mail]>]

On 08/09/2014 17:12, Watson Ladd wrote:
> On Mon, Sep 8, 2014 at 7:30 AM, Manuel Pégourié-Gonnard <[e-mail]> wrote:
>> By the way, the TLS curve/point negotiation doesn't allow peers to negotiate the
>> use of different point formats for different curves. That's probably something
>> to bear in mind when discussing point formats.
> 
> I think that is more wrong than right. 

Or maybe just not clear enough, sorry for that. Let me expand a little bit,
assuming Curve25519 (for the sake of the example) is standardised, the CFRG
and/or the TLS WG will have to choose between the following options:

1. Use only short-Weierstrass format for point transmission, for this curve as
well as the others, meaning that no new point format is added, but
implementations have to either convert between representations, or use the
classic code for short Weierstrass arithmetic.

2. Use only Mongtomery-x format with this curve (and maybe other new curves
supporting it, but obviously not with the NIST and Brainpool curves).

3. Allow both formats, with the idea that implementations are free to choose. My
point was, this is not as good an idea as it might seem, since currently an
implementation has no way of saying "I support the short Weierstrass point
format(s) with the NIST/brainpool curves, and Montgomery-x with Curve25519, but
not short Weierstrass with Curve25519 (since I want to use the Montgomery ladder
but didn't implement conversion between short-Weierstrass and Montgomery)".

I'm not saying this is a big issue, just something we might want to keep in
mind. Of course TLS could change its negotiation procedure to negotiate (curve,
point format) pairs instead, but I'm not sure it would be a good thing, esp. if
we want it to be usable before TLS 1.3.

I thought about this while reading djb's email about the fact that the new
curves allow more options, since they can be converted to short Weierstrass
representation. It's entirely correct of course, but it might be good to
restrict that flexibility (options 1 and 2 above).

> Currently all curves are short
> Weierstrass. If we say "curveXYZ means you do this instead, and adjust
> the point formats accordingly", is that really a problem? Certainly
> the Curve25519 in TLS draft didn't think so.
> 
That would be option 2 above, which is not a problem. I was trying to warn about
option 3.

Manuel.