Re: [Cfrg] Curve25519 (and Safecurves more generally)

[Paul Lambert <[e-mail]>]

On 1/6/14, 5:37 PM, "Watson Ladd" <[e-mail]> wrote:

>Paul Lambert has stated that industry doesn't have the guts to take
>responsibility for using this in products and would like to blame us
Not quite what I stated Š I¹ll assume it¹s humor.


>if it goes bad, since they can't blame NIST. (In what other industry
>does "we don't stand behind our products, because we don't have the
>expertise to determine how good they are" count as acceptable?)

Clarity in the documentation of the review and diligence associated
with the selection of algorithms is critical for Œreal¹ products.
It needs to be something that can be referenced for both it¹s review
and recommendations and for implementation details and guidelines

>
>The question to be answered is as follows: is the curve
>y^2=x^3+486662x^2+x over the prime field 2^{255}-19 an elliptic curve on
>which the DDH is believed to be acceptably hard to provide 128-bit
>security?
>
>My firm belief is that the answer is yes. There is no known reason why
>this curve
>could be weak and 486662 is the smallest integer for which this curve
>shape is strong.
>This curve shape is not particularly special. The only specialness is
>the prime, but
>that isn't known to do anything.

I am supportive of the curve, but the change in curve shape does
impact the underlying code for the point operations.
Clarity in the definition of these functions would be vey valuable.

One worked example of defining curves is:
http://www.secg.org/index.php?action=secg,docs_secg

I believe these specifications could have been simpler looking at
the algorithms from an implementation perspective versus the math.

RFC 6090 is another good example of the required work.

Paul


>
>I would also like to ask this for each curve in Safecurves claimed to
>be safe. Note that some numbers in the above question need to be
>changed: I leave this as an exercise to the reader.
>
>Is an RFC required to express this opinion? If so I'll write up the
>shortest ID on record to define the model of each curve, and provide
>the canonical basepoints on each. Would anything more be required for
>these curves to count as appropriately blessed?


>
>Lastly, there is a long tradition of providing challenges with
>monetary rewards for cracking parameter choices. Bitcoin makes this a
>bit redundant, so I will refrain from putting my own money as a prize
>for ECC breaking.
>
>Sincerely,
>Watson Ladd
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg