Subject: Re: [Cfrg] draft-ladd-safecurves-02

From: Dan Brown <[email-masked]>
Date: Sat, 11 Jan 2014 00:37:04 +0000

I didn't agree with all the arguments on the Safecurves URL, at least when I last read it a few months ago. Nor did I agree with all DJB said on the TLS WG list.

I'm going to try to write up to CFRG my disagreements soon.

Maybe I'm old school, but I'd expect references to be stable and dated. Even if CFRG consensus (eg all minus me) fully agrees with the site today, the site could change, in a way not expected.

The CFRG consensus may also be to move ahead with these curves, without agreeing fully with the site.

So it might help for the spec to state the CFRG's rationale for accepting these curves.

More practically, ideal would be to advise users of the advantages and disadvantages of these curves, over others.

From: Watson Ladd
Sent: Friday, January 10, 2014 6:31 PM
To: Alyssa Rowan
Cc: [email-masked]
Subject: Re: [Cfrg] draft-ladd-safecurves-02

On Fri, Jan 10, 2014 at 11:48 AM, Alyssa Rowan <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 10/01/2014 19:11, Watson Ladd wrote:
>
>> Added: explicit formulas and a point format (big endian with a bit
>> for the missing coordinate).
>
> Fair enough. (Cofactors were also added, by the way.)
>
>> The name is now the Chicago curves.
>
> As good as any other.
>
> Comments:
> • Typo in end of section one: Weierstrass, not Weierstrauss.

Fixed

> • I think it'd be a little more helpful if section 2 were split into
> two sections: the Montgomery curves, and the Edwards curves. That'd
> make it much more apparent which curves are applicable to which
> sections in 3 and 4.

I'll think about a clean way to do this. Of course, you can use
isogenies to convert
between all of these forms.

> • Pretty please can we have Curve1174 as well?

Included.

Anymore suggestions? This next one it would be nice to get Last Call on.
>
> Other than that, no more comments.
>
> E-521's passed all tests, by the way, as expected (and it seems was
> obviously rigid enough that three groups actually came up with the
> exact same curve!).
>
> I see no particular reason to hold this up.
>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJS0E6JAAoJEOyEjtkWi2t6V3wP/0CHxxQtWozhfilM5BY+6Ffw
> PosRUsiRAA6V5UCeAiQUWzBUjIhV8kgyQSYTSuxgFNOASFMVIs24sSs48nLcUYjR
> ER+Hmtl8La6OJ/cR0iAaP92PY9UScbUFzWPAJXOljGTPYH7D7dykdAUSnfN5vfy4
> IeBdkJm66C/JYRwq20y3noSlQfJfclJYDOJIscUco6TYGV3/eLjiMFVFQfzAjJlz
> RHDwYbr8Quc2lr4Hjl4mm+NRHFdUskhD4i7lA0DfcjohILxC4dw71f5wlmDehuMI
> /MGccPbcPfQ0lEJpq5E3cY3jNtPU+EonY4TNnBA9mg2a2wVm2iIGOatptEzo+R7Q
> fsjw+i2MXML+gNqpspGcA5RPU3x0DHSSzu5DDhpRH5V+So51mVdXFjGeLrLK1gJk
> CZnOdDGgwc1tmOaphWMZZdcCYZosm8UMqh/J5tHCqUooknWxzVEKUs7eyn3TG6+I
> +gdtbOdZhQf0K8iIXtwc874+G+e2c0MiU64GkNN3UT/7QFQY5zVxcgDLXwzUHcZk
> PXx55n5IFz7iTwjTZd859grGRubHHjqDnnE/gNeWp7iGq2UezYMiRcLJUCehglYi
> 72bAdbRc/bLOBoIHzJSuqEDR0TKRFmmrIN0pfSJe7PO9iun3b/rLIYavDfwH8dLN
> NfKGARVJurKm1aW7wFk5
> =PsP0
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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
_______________________________________________
Cfrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 10 Jan 2014 17:01:01 -0800

> I'm going to try to write up to CFRG my disagreements soon.

Do you believe these curves are insecure? Because people want to use
them. They pass every known criterion for ECC security.
Just because you don't like the rationale vs. P256 (massively higher
performance in software, better twist security) doesn't mean that
they aren't a valuable option to have, particularly if the suspicions
about the random seeds are verified.

Furthermore, are you objecting to the draft, or to DJB? Because one of
those is under discussion here.

> Maybe I'm old school, but I'd expect references to be stable and dated. Even if CFRG consensus (eg all minus me) fully agrees with the site today, the site could change, in a way not expected.

The rationale for picking a curve is not a normative feature of a
specification. However, validating that these numbers are prime
doesn't take that long. The twist order is the order of the curve with
a known adjustment, and so can be validated given only that the
cofactor and prime order are correct. The Hasse-Weil bound makes this
validation easy if you know what it is supposed to be. Safecurves only
contains a proof of primality open
to human verification. If you want, run RUNDOWN and stick the results
in here. But that would be a bit ridiculous.

If DJB and Tanja Lange publish Safecurves in a more stable form, we
could cite that. Or we could base64 the verification script and ram it
in an appendix. Or we could assume that everyone that paranoid has
PARI to do the work.

> The CFRG consensus may also be to move ahead with these curves, without agreeing fully with the site.

How is the current text in any way an endorsement of a website? This
concern is specious.

> So it might help for the spec to state the CFRG's rationale for accepting these curves.

Why would the CFRG have a shared rationale? Some people might like
efficiency, others the compact form of points, others the
non-NISTiness.

> More practically, ideal would be to advise users of the advantages and disadvantages of these curves, over others.

More than the security considerations does now? Efficiency is
constantly changing as people optimize the heck out of one or another
thing, and so I don't feel like it belongs here. Security
considerations are I think well covered: the cofactor tradeoff is a
well-studied one, and can't bite that hard.

What advantages and disadvantages do you feel require additional
coverage? Why do you think this material belongs in this I-D?

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 11 Jan 2014 16:57:52 +0100

> I'm going to try to write up to CFRG my disagreements soon.
I'm looking forward to reading them.

FWIW, I don't agree with every argument as stated on the site (eg, I don't
believe it's fair to quote "no data-dependant branches or memory access
patterns" as properties of the curves), but I still think those curves are an
interesting addition to the current set of curves mainly for the following reasons:

* no unexplained constants as opposed to the NIST "random" prime curves (and
better performance than the Brainpool curves). Even if NIST curves turn out not
to be weak, we currently don't know, and doubt is an issue in itself.
* ease of (correct) implementation
* performance.

> Maybe I'm old school, but I'd expect references to be stable and dated.
> 
Agreed.

Manuel.

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 11 Jan 2014 16:24:56 +0000

> I'm going to try to write up to CFRG my disagreements soon.

I am quite sure I shall find them interesting.

> Maybe I'm old school, but I'd expect references to be stable and

Agreed there. That's a temporary slot, there for the draft, I believe,
but the final reference should I think be more like:

7. References

   [SAFECURVES] Daniel J. Bernstein and Tanja Lange. SafeCurves:
   choosing safe curves for elliptic-curve cryptography.
   <http://safecurves.cr.yp.to>, accessed 11 November 2014.

   [EFD] Daniel J. Bernstein and Tanja Lange. Explict-Formulas
   Database, Genus-1 curves over large-characteristic fields.
   <http://www.hyperelliptic.org/EFD/g1p/>, accessed
   11 November 2014.

Oddly, archive.org hasn't saved the most recent version. I don't
expect it to disappear, but this RFC is of course going to be around
for a long time.

If anyone knows of a better way to formally cite a webpage in an
informational RFC, please say so; there's very likely already a
process for that which I'm unfamiliar with?

> […] it might help for the spec to state the CFRG's rationale for
> accepting these curves. More practically, ideal would be to advise
> users of the advantages and disadvantages of these curves, over
> others.

Section 1 of the draft would appear to meet that need quite well
already. I'm comfortable with it as it stands.

- -- 
/akr

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Jan 2014 08:39:56 -0800

>    <http://www.hyperelliptic.org/EFD/g1p/>, accessed

Published academic papers would be *much* more useful than web sites that can change.

References in RFCs are not there to prove that the RFC authors did their homework; they are there to help readers assess the validity of statements in the document. When someone reads this RFC 15 years from now, the contents of http://safecurves.cr.yp.to will very likely be more up to date, possibly in a way that negates some of what is said in the document. A reader of the RFC at that point should decide not to implement because of the disagreement between the RFC and the reference; that would be bad.

For crypto documents, references to books (specific editions) and IACR papers seem to work just fine.

--Paul Hoffman

---

From: David McGrew <[email-masked]>
Date: Tue, 14 Jan 2014 16:05:57 -0500

> References in RFCs are not there to prove that the RFC authors did their homework; they are there to help readers assess the validity of statements in the document. When someone reads this RFC 15 y…

Plus one; this is an important point.

David

---

From: Watson Ladd <[email-masked]>
Date: Tue, 14 Jan 2014 13:24:35 -0800

On Tue, Jan 14, 2014 at 1:05 PM, David McGrew <[email-masked]> wrote:
>> References in RFCs are not there to prove that the RFC authors did their
>> homework; they are there to help readers assess the validity of statements
>> in the document. When someone reads this RFC 15 years from now, the contents
>> of http://safecurves.cr.yp.to will very likely be more up to date, possibly
>> in a way that negates some of what is said in the document. A reader of the
>> RFC at that point should decide not to implement because of the disagreement
>> between the RFC and the reference; that would be bad.

Possibly not: if a new attack is discovered that safecurves.cr.yp.to
tells the world about
before we catch up, it would be great if someone doesn't implement
because of that.

> Plus one; this is an important point.

And is addressed in the latest draft. (Not yet posted)

Much more substantive is the desire for material on the lines of RFC
6090 to be added: that will take considerably
longer than anticipated. But we have to wait for OIDs anyway.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 14 Jan 2014 14:29:57 -0800 (PST)

On Tue, January 14, 2014 1:24 pm, Watson Ladd wrote:
>>> Published academic papers would be *much* more useful than web sites
>>> that
>>> can change.
>>>

  There are a number of reasons (left unsaid to prevent this thread from
derailing) that safecurves.cr.yp.to might not even exist as a website
in 15 years. An reference that says a web page was "accessed on"  some
date is not acceptable.

> longer than anticipated. But we have to wait for OIDs anyway.

  Your draft is really part RFC 6090 and part RFC 5639. You need to
explain the math background (which is different than that in RFC 6090),
the requirements that resulted in the groups being generated, and the
parameters that define the groups. Then you need to define the complete
domain parameter sets, list the OIDs that refer to them, and a set of test
vectors for each group-- suggest just doing an Alice and Bob ECDH
exchange.

  A section on why Joe Random should select these curves for his
implementation would be most helpful.

  Dan.