Re: [Cfrg] Safecurves draft

On Wed, Jan 8, 2014 at 12:50 PM, Paul Lambert <paul@marvell.com> wrote:
>
>
>> -----Original Message-----
>> From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Dan Harkins
> ...
>> On Wed, January 8, 2014 9:58 am, Watson Ladd wrote:
>> > On Wed, Jan 8, 2014 at 9:21 AM, Stephen Farrell
>> > <stephen.farrell@cs.tcd.ie> wrote:
>> >>
>> >>
>> >> On 01/08/2014 05:11 PM, Watson Ladd wrote:
>> >>> Dear all,
>> >>> draft-ladd-safecurves contains the Safecurves with orders
>> >>> 2^255+\epsilon and higher.
>> >>> I forgot to update the TOC, but that shouldn't stop the substantive
>> >>> conversation.
>> >>>
>> >>> Does anyone object to these curves being approved for IETF standard
>> >>> body use/typos/general nastiness?
>> >>
>> >> No objection, but there's maybe some checking to be done before
>> we're
>> >> ready to push the button.
>> >
>> > Absolutely! Please double check I didn't make any typos, and if you
>> > have MAGMA access, redo the verifications. This goes for everyone.
>> The
>> > more eyeballs on this, the less chance we make a bad mistake.
>> > safecurves.cr.yp.to comes with a script to redo everything.
>> >
>> > Also, if anyone knows something that DJB and Tanja Lange do not,
>> > please tell us!
>> >
>> >>
>> >> One thing though is that rfc 3526 [1] is standards track so if
>> >> there's a reason for that (and there may or may not
>> >> be;-) then we might want these to be the same which'd mean not doing
>> >> 'em in cfrg. That can be figured out later though.
>> >
>> > I have no opinions about how this gets to from draft to RFC.
>>
>>   Which is good because the process from draft to RFC is already well-
>> defined. It's on the IETF web site, check it out!
>>
>> > I understand there are many channels, and someone will have to pick
>> > one.
>>
>>   And that someone would be you!
>>
>>   While it's certainly useful to get these curves defined in an IETF
>> document, getting them used by any protocol will require some more work
>> from you. You should get OIDs defined for each of them if they don't
>> exist already. You should write up separate drafts for inclusion of
>> these curves into the protocols' various IANA-managed repositories--
>> yes, sadly there are many. And for protocols which allow for in-line
>> passing of complete domain parameter sets (like TLS) you'll need to
>> modify the data structure used (doesn't look like these could be used
>> with the "explicit_prime" ECCurveType, for instance).
>>
>>   On the plus side, for the most part you can just follow the path
>> blazed by the brainpool folks, just follow what they did.
> 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?
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.

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?
>
>
>>
>>   Welcome to the tedious world of sausage making, don't mind the blood
>> on your hands, you get used to it.
>>
>>   Dan.
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> 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