Re: [Cfrg] Safecurves draft

[Watson Ladd <[e-mail]>]

On Wed, Jan 8, 2014 at 4:30 PM, Paul Lambert <[e-mail]> wrote:
>> > You should also look at: RFC 6090
>> > The math for Small Wierstrass curves is defined well - you need the
>> > equivalent of
>> > 6090 for Edwards curves.  Do note the authors of this excellent RFC
>> > Include both chairs of this list.
>>
>> First, is this advising me on next steps, or is it an objection to the
>> draft?
> Next steps.  I'm very supportive of the inclusion of these curves into the main stream.
>
>> The group is [l]Jac(E(F_q)). There, done. In fact, this is in the
>> introduction.
>> The equivalent to RFC 6090 is the Bernstein paper on addition on
>> Edwards (and twisted Edwards curves).
>> It's readily available. If you want to reformat it as an I-D, go right
>> ahead.
> Academic papers are not appropriate directly.  Clear and concise algorithm
> descriptions and guidelines are required.

But the explicit formulas aren't actually required for intereop. I'll
put them as informational because it took me a few minutes to
write them down in the draft, and I don't mind that much.
 We don't define how TCP clients should maintain the buffer of sent
information efficiently, or how
routers should maintain the routing tables. OSPF doesn't explain how
to maintain a binomial heap.
This sort of information might belong in an RFC. But its lack doesn't
make a standard insufficient.

Anyway, this is totally immaterial: the next version, which fixes some
typos, adds E-521, and removes a badly designed
curve (secure but slow), adds in a section explaining the formulas
will hit the RFC editor some time next week: I want to collect
more comments and resolve them.

Take a good look for typos: that's what can really mess this whole thing up.

Anyway, once I get the next version up, I think we'll pretty much be
ready on this, assuming no major dealbreakers appear.

>
>
>>
>> Is it really that bad to have the EFD get cited for the formulas, or to
>> advise implementers to read Handbook of Elliptic and Hyperelliptic
>> Curve Cryptography?
> Yes.  They are not standards.  They are not always precise and subject to
> Interpretation and bad implementation.
> They are not complete ... Dan's point about OIDs and the like required
> to actually use the curves.

One of the big obstacles to the curves you mentioned was the lack of
vetting. That's gone now: you can point to it in an RFC when this gets
published. As a result when it comes to designing or revising old
standards, it won't be harder than putting any other curve now.

I'm very much against protocol design that involves lots of options: I
like these curves because they have great implementations with
liberal licensing available now. You can use these curves today with
just a choice of big or little endian, and software that sets speed
records.

Adding in the apparatus in each protocol is obviously going to take
longer, depending on how bad the protocol is to work with. But
I don't think CFRG is the right place for that.
>
>
>
> Paul



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