Re: [Cfrg] Safecurves draft

[Paul Lambert <[e-mail]>]

On 1/8/14, 4:58 PM, "Watson Ladd" <[e-mail]> wrote:

>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.
Comment: 
 -too terse
 - no clear mapping of numbers to variables
 - no documentation of Edwards point addition
   Which is different from durrent ECC drafts
 - no indication of security concerns and
  need or lack of checking public key values
 

Here¹s how I¹d document curve parameters:

class Curve3617(EdwardsCurveFp):
    curveId  = 'curve3716'
    strength = 207
    oid = None
    p  = 2**414 - 17
    d  = 3617
    xG = 0x1a334905141443300218c0631c326e5fcd46369f44c03ec7f5\
         7ff35498a4ab4d6d6ba111301a73faa8537c64c4fd3812f3cbc595
    yG = 0x22
    n  = 2**411 - 
33364140863755142520810177694098385178984727200411208589594759


 


Paul

PS - above parameters are directly executable Python code
     Why use pseudo code when you can use real code :-)



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