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

["Dan Harkins" <[e-mail]>]

On Tue, January 14, 2014 1:24 pm, Watson Ladd wrote:
> On Tue, Jan 14, 2014 at 1:05 PM, David McGrew <[e-mail]> wrote:
>> On 01/11/2014 11:39 AM, Paul Hoffman wrote:
>>>
>>> On Jan 11, 2014, at 8:24 AM, Alyssa Rowan <[e-mail]> wrote:
>>>
>>>> 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.
>>>
>>> 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.
>
> 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.

  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.

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

  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.