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

From: Watson Ladd <[email-masked]>
Date: Mon, 6 Jan 2014 17:37:44 -0800

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

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

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Jan 2014 12:53:07 -0800

>responsibility for using this in products and would like to blame us
Not quite what I stated Š I¹ll assume it¹s humor.

>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

>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

>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg