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

From: Kurt Roeckx <[email-masked]>
Date: Mon, 2 Feb 2015 23:29:19 +0100

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.

Kurt

---

From: Watson Ladd <[email-masked]>
Date: Tue, 3 Feb 2015 08:50:43 -0800

> 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.

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.

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.

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.

When should we expect last call on a draft that describes Curve25519?

Sincerely,
Watson Ladd

>
>
> Kurt
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 3 Feb 2015 17:39:30 +0000

Dear Watson,

>There are no security concerns with Curve25519.

That is the consensus.

>would already have included it as an option.

It could, but then we would not have delivered what we were asked to
deliver by TLS WG. That was: to recommend curve or curves (and by
implication, algorithms using those curves) at a variety of security
levels. That required a more considered evaluation of the broader space,
not a single recommendation on Curve25519.

>levels to worry about, with about 10 emails total on these topics.

If you take the total discussion we've had over the last 9 months, then
there's significantly more than 10 e-mails. I think this has established a
pretty good understanding in the RG around the key issues. Making progress
should not require rehashing all of that (please!).

>should be big or little endian, after the TLS WG already had this

Did you count how many of those 90+ e-mails you sent yourself? On a blog
post elsewhere [1], you describe CFRG as being "more dysfunctional than
usual". I suggest it's incumbent on you to reflect carefully on the
reasons why that might be....

>March (several hard deadlines),

The editors are in place. The chairs needed some time to appoint the
editors because of the initial document from Adam essentially being a
merge of other authors' documents.

>despite dropping several deliverables

It's not. It's going to be part of it, but we need more than X25519 to
meet the request from the TLS WG.

Right now, Alexey is out of action, but as soon as he is back, the chairs
will be moving the technical discussion forward and seeking consensus on
the key issues that still face us before we can deliver to TLS WG.

More soon.

Regards

Kenny 

[1] http://automorphy.blogspot.co.uk/?m=1

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 3 Feb 2015 19:27:59 +0100

> would already have included it as an option.

Is there a consensus that Weierstrass is the way to go for
curve25519?  Why not Montgomery?  As far as I know the current
draft has Montgomery in it and it seems to make more sense to me.

Kurt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Feb 2015 14:03:26 -0500

> 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?

> 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.

> should be big or little endian, after the TLS WG already had this

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.

> to make it, and knowing that X25519 is going to be what is in the

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.