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

Paul Lambert <> Wed, 08 January 2014 20:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9235B1AE5B7 for <>; Wed, 8 Jan 2014 12:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OQRdw0JxCxmz for <>; Wed, 8 Jan 2014 12:53:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 728BC1AE5B5 for <>; Wed, 8 Jan 2014 12:53:20 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s08Kq4YX020076; Wed, 8 Jan 2014 12:53:10 -0800
Received: from ([]) by with ESMTP id 1h88776h0t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Jan 2014 12:53:10 -0800
Received: from ([]) by ([::1]) with mapi; Wed, 8 Jan 2014 12:53:09 -0800
From: Paul Lambert <>
To: Watson Ladd <>, "" <>
Date: Wed, 8 Jan 2014 12:53:07 -0800
Thread-Topic: [Cfrg] Curve25519 (and Safecurves more generally)
Thread-Index: Ac8Ms6MgeVnenHpcTZGiL5pm8dpp4w==
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-08_08:2014-01-07, 2014-01-08, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401080126
Subject: Re: [Cfrg] Curve25519 (and Safecurves more generally)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jan 2014 20:53:21 -0000

On 1/6/14, 5:37 PM, "Watson Ladd" <> 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
>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:,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.


>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.
>Watson Ladd
>Cfrg mailing list