Re: [Cfrg] Suggestions for draft-irtf-cfrg-curves-01.txt

On 2/2/15, 8:35 AM, "Watson Ladd" <watsonbladd@gmail.com> wrote:

>On Mon, Feb 2, 2015 at 7:07 AM, Evgeny Alekseev <eamsucmc@gmail.com>
>wrote:
>> Stanislav V. Smyshlyaev wrote:
>>
>>> Dear colleagues,
>>>
>>> We would like you to consider several proposals on the latest variant
>>>of
>>> draft (draft-irtf-cfrg-curves-01).
>>>
>>> 1)      In our opinion, some important clarifications have to be done
>>> explicitly in the document, though needed references are given.
>>>  a) In Section 3.3 declare explicitly what "r² denotes.
>>>  b) In Section 5 mention explicitly SchoofElkiesAtkin algorithm as an
>>> algorithm used to calculate number of curve points or even fully cite
>>>it
>>> there.
>>>  c) Add explicit description of algorithms used to examine curve on
>>>MOV-,
>>> CM- and twist-security as well as Frobenius trace calculation formula.
>>>Add
>>> ³perform checks² step in algorithms proposed in sections 5.1 and 5.2.
>>> 2)      Select and add a higher security curve (512- or 521-bit).
>>> 3)      Add some explanations on parameter d of the selected 255-bit
>>>curve
>>> (the current draft leaves the question whether it is the first d to be
>>> returned by 5.2 algorithm and the reason of choice if it is not).
>>> 4)      Introduce a rigid base point generation algorithm (either the
>>>one
>>> that was proposed in the previous version of the draft or one using
>>> cryptographic hash function). We consider that important to ensure the
>>> generated points > could be safely used in applied protocols like
>>> password-based key establishment protocols (PAKE, EKE, PACE etc.) and
>>>RNGs
>>> like Dual EC DRBG.
>>>
>>>
>>> Best regards,
>>> Stanislav V. Smyshlyaev, Ph.D.,
>>> Head of Information Security Department,
>>> CryptoPro LLC
>>
>>
>> I agree with Stanislav Smyshlyaev¹s questions and suggestions about
>>current
>> draft version. I would like to draw attention to the 3d remark. If the
>> answer to this question ("... whether it is the first d to be returned
>>by
>> 5.2 algorithm ...") is ³no² then it turns out that extra requirements
>>that
>> are not mentioned in the draft are implicitly applied to the curve.
>>Also it
>> seems strange that the recommended curve is not the one with the
>>smallest d,
>> but the isogeny of this curve. Also I would like to add that it would be
>> convenient if the recommended Edwards curve is included in the document
>>in
>> the same way as twisted Edwards curve.

+1

>
>The recommended curve is y^2=x^3+486662x^2+x. Were we to use an
>isomorphic curve, as opposed to a 4-isogenous one, that 486662 would
>be replaced by a larger number, and thus slow down implementations
>significantly. Note that 486662 is the smallest value of a that
>ensures that
>y^2=x^3+ax^2+x has order 8*prime, twist order 4*prime, and the usual
>CM restrictions. This is the same as 121665 being the smallest d that
>ensure that y^2+x^2=1+dx^2y^2 has the same order and CM restrictions.

So Š the designated editing team will process the above answer
and create suitable text for possible inclusion into the
draft specification.  Yes?

Paul

>
>Sincerely,
>Watson Ladd
>
>>
>> Kind regards, Evgeny Alekseev, Doctor of Philosophy,
>> Moscow State University, Faculty of Computational Mathematics and
>> Cybernetics
>>
>>
>>
>> _______________________________________________
>> 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
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg