Re: [Cfrg] Chopping out curves

Adam Back <> Fri, 17 January 2014 12:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E4341AE097 for <>; Fri, 17 Jan 2014 04:42:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wlfjzo-vIxIb for <>; Fri, 17 Jan 2014 04:42:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1AB341AE08C for <>; Fri, 17 Jan 2014 04:42:23 -0800 (PST)
Received: from netbook ( []) by (node=mrus4) with ESMTP (Nemesis) id 0LpsQp-1VS4Ms1jWh-00f0aw; Fri, 17 Jan 2014 07:42:09 -0500
Received: by netbook (Postfix, from userid 1000) id 89CC72E0129; Fri, 17 Jan 2014 13:42:03 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000); Fri, 17 Jan 2014 13:42:00 +0100
Date: Fri, 17 Jan 2014 13:41:59 +0100
From: Adam Back <>
To: Alyssa Rowan <>
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 000000000000000000000000Af7V
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V02:K0:Yd6oezk929HqP2c6zWViTYiwmWeL8Xf0A6a4O3zphgs UUCUZrgQcnRK41vGFWcVp2oT8twdzapzugNkvuMe2zyjxDms/Z wQvPpC7nG5mwZMa6CD7NUXA8q5MGZDRiqixenbOP1aaZU9Kl/j SJy3S1Y+eSpHicn2ndB5p07K67m4ep8S3ujuATeJIU42JepKx5 Ny9SG8hblC5zqMtzashODD4j0bMGVt9tob/O7OfcvVEPj5ihLu gD6UyIqYN3P5wd6pEFPQQGIEF7yp8I2aF1Wyq6HaW/vY4WbcwF tS3E+NFSw/fWZJeF0oQJfdIzVb0qxCwX0CiWk8dVtwreElECP4 HJ/YFgXRNcwL6qWsPAkc1GoPuSnvoANzhBhK/yBOd
Cc: Adam Back <>,
Subject: Re: [Cfrg] Chopping out curves
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: Fri, 17 Jan 2014 12:42:25 -0000

I'm not sure if we should be going as far as generating new curves, or
significantly tweaking choices in the existing curves in incompatible ways
(eg new generators), I thought original idea was more to provide in RFC
format the best rigid/NUMs curves available that people are already starting
to use so they at least have a reference.

Generating new curves or significantly deviating from them or their exiting
parameter choices, creates our own NUMs risk, and a restart on the review
process, creates something that needs to have its own (maybe derivative)
name, and places CFRG in the biased editorial position of both generating &


On Fri, Jan 17, 2014 at 07:41:53AM +0000, Alyssa Rowan wrote:
>Hash: SHA512
>On 17/01/2014 02:36, Adam Back wrote:
>> Uh I meant the Curve25519 and Curve3617.
>We have three key sizes for AES, and three hash sizes with SHA-2 and
>SHA-3 (and the candidates).
>I propose:
>• curve25519 (plus twist t25519)
>• curve3617
>• e521
>That gives us three curves with strength roughly congruent to the 128,
>192 and 256 key sizes, and about as good performance as we're going to
>get for those levels.
>curve25519 is likely to be used for high-performance ECDH; its twist
>is likely to be used for high-performance encryption and signing.
>curve3617 seems likely to be used for higher-assurance encryption and
>signing (Silent Circle intends to use it, for one).
>e521 is slower, but very conservative - maybe you'd want to use it for
>very careful signatures or encryption; the prime field is of course a
>well-known Mersenne prime people are already used to (thanks to
>secp521r1), and it's so rigid, three people came up with the
>parameters independently.
>I wouldn't cry a river if we dropped e521 from that list.
>Those are, I think, the two or three that applications are most likely
>to actually want to use in practice.
>Regarding the t25519 basepoint, the argument for using the ed25519
>basepoint is that it's already out there and thus already rigid, but
>yes, it is ugly.
>If you do choose a new basepoint, Watson (and I can see the sense in
>that), please rigidly document the choice criteria so the decision can
>be independently verified and confirmed (minimal y, right?).
>I haven't had my first cup of tea yet today, so I apologise if I'm
>wrong, but I believe any new basepoint would need to go through the
>SafeCurve verification tests again, because ℓ would change? - run it
>yourself for sanity checking, and please post the source files on the
>list so we can use Sage or something to verify it too, but please also
>speak to Tanja and djb about that to get wider verification.
>- --
>Cfrg mailing list