Re: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Feb 3, 2015 at 11:50 AM, Watson Ladd <[e-mail]> wrote:

> On Mon, Feb 2, 2015 at 2:29 PM, Kurt Roeckx <[e-mail]> wrote:
> > On Thu, Jan 29, 2015 at 10:09:18PM +0000, Dan Brown wrote:
> >> New thread name ... should have done so earlier.
> >>
> >> When TLS asked CFRG for new curves, I didn't interpret that to mean that
> >> generic curves would be banned. Banishing generic curves adds slightly
> more
> >> weight to the TLS request, because users cannot easily opt out of the
> chosen
> >> few elite curves.
> >
> > If it's unclear what the TLS WG wants exactly, maybe it's best to
> > ask them?
> >
> > My understanding is that they want fixed named curves.
>
> Let me get this right:
>
> There are no security concerns with Curve25519.
>
> For the entire 12 months we've been piddling away, we could have
> written Curve25519 in Weierstrass form, and the TLS specification
> would already have included it as an option.
>

No I don't think that is correct. The arguments for Curve25519 are

1) Performance
2) There is not enough difference between 255 and 256 to be worth arguing
over
3) Legacy implementation
4) Avoidance of patent issues.

Weierstrass form would not address the last two.

If I end up having to get up in court as an expert witness, it is a lot
easier for me to show someone that the Edwards version of a curve does not
infringe some Weierstrass related twiddle than it is for the competing
expert to convince a jury that Weierstrass and Edwards forms are isomorphic.


Seriously guys, how many folk do you think we have in the community who can
explain this stuff to a jury and how many of those would you want to put
anywhere near a jury hearing a case you had an interest in?



> We've still got signatures and the choice of primes at higher security
> levels to worry about, with about 10 emails total on these topics.
>

I must have written 20+ on the higher security curve:

* I don't think there are going to be fully objective criteria.

* I really don't want to go over 512 bits because it breaks stride. I
already have hardware with 512 bit data paths. I do not expect to have
hardware with a 1024 bit path and if I did I would want to make full use of
it.

* I don't care about a performance difference unless it is at least a
factor of two.

* 512 bits is a really nice round number.


Instead we've spent 90+ emails debating whether an opaque byte vector
> should be big or little endian, after the TLS WG already had this
> debate.
>

And I don't think it is even in scope for CFRG. TLS handles ephemeral keys
and PKIX keys in different ways. There is no requirement for both to be
handled the same way.

It is very clear that the PKIX representation has to be big endian because
the ASN.1 code that maps RSA keyinfo data to internal math structures is
going to be the same code folk want to use for ECC.

So basically TLS has to choose between having the ephemeral ECC structures
be consistent with the legacy Curve25519 implementations or be consistent
with the PKIX Keyinfo specification. End of story.


> We've exceeded a previously announced deadline by a month. We're still
> picking editors for a draft that has a hard deadline coming up in
> March (several hard deadlines), despite dropping several deliverables
> to make it, and knowing that X25519 is going to be what is in the
> eventual RFC.


Was this a surprise to you?

I remember attending one of the SDMI conferences where the speakers on the
podium assured us that there would be a spec by Xmas because there must be
one by then. They were still at it two years later.