Re: [Cfrg] Thoughts on a Next-Generation Elliptic Curve Signature Scheme?

Robert Ransom <> Sat, 11 January 2014 18:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E3E541AE14E for <>; Sat, 11 Jan 2014 10:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aNeE0PVGgJIL for <>; Sat, 11 Jan 2014 10:44:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::235]) by (Postfix) with ESMTP id 91D1B1AE142 for <>; Sat, 11 Jan 2014 10:44:47 -0800 (PST)
Received: by with SMTP id e9so4990832qcy.12 for <>; Sat, 11 Jan 2014 10:44:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DQYFiiAW3b6O4s/teoBPGhBjheSwI6/nOAAyb/FC49g=; b=h1aLAZSnE5PQBUDKDG3N9/SW/5G4Av0tDvaXULIR7csZBEXeQZnnzPWFRg+p7jYPPx WpUWEpBOROIlLmrG9LKyEPXzCRQCdOjwVYMpoR77VuxdFRHLFuGMASK92GxvGF6dLY13 pwc6iVXA7/n63ec/GVGmb/uvSi2vr+o93ntvmYDUdcNecTKNVU3ASwSEBMdMj+Fa0KWn OgM1HqXNHvguxXqAMMaTv+QHpYL3FqXO4QcUW1xdJaeb0lznnvmFC5S123KPkMkZCevT lTlGUqbSdrCxqaqYkkEOftHkAgUtx8trqatoPpcnkre8HEVCTGqCDJJ41Zn4PMF46jeK /DoA==
MIME-Version: 1.0
X-Received: by with SMTP id e4mr21391394qco.2.1389465877138; Sat, 11 Jan 2014 10:44:37 -0800 (PST)
Received: by with HTTP; Sat, 11 Jan 2014 10:44:37 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Sat, 11 Jan 2014 10:44:37 -0800
Message-ID: <>
From: Robert Ransom <>
To: Alyssa Rowan <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Cfrg] Thoughts on a Next-Generation Elliptic Curve Signature Scheme?
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: Sat, 11 Jan 2014 18:44:49 -0000

On 1/11/14, Alyssa Rowan <> wrote:
> Hash: SHA512
> At some point, clearly we're going to need a signature scheme for
> these "Chicago curves" specified in SafeCurves, for later use to
> replace ECDSA with something which is a more convenient fit for them
> and doesn't want random numbers for each signature, for future use in
> certificates, authentication, and the like.
> I feel like now would be a good point, hence this request for ideas.
> On 11/01/2014 17:40, Robert Ransom wrote:
>> Dr. Bernstein's EdDSA is even worse: it prohibits every curve that
>>  Dr. Bernstein himself has specified since Curve25519.
> EdDSA seem like a pretty good start for a new signature scheme to me,
> even if as it stands I think it's closely tied to Ed25519 itself
> (basically, due to the size and construction?).

EdDSA specifies some details that are irrelevant to how the signature
scheme works: it specifies that the coordinate field's order must be
congruent to 5 mod 8, and it specifies that the curve group must have
cofactor 8 (cofactor 4 is possible even mod 2^255 - 19, e.g. a=-1,
d=446 if I'm retyping it correctly).

> Either the Edwards curves or the Edwards isomorphism of one of the
> Montgomery curves would do, although the ones specified as Edwards
> curves would likely be cleaner, particularly Curve1174, Curve3617 and
> E521: in fact, those would be the three I'd plump for, as I think they
> provide three pretty good security/efficiency points.

Please, not Curve1174.  If you don't like Curve25519's awkward
fractional value of Edwards-form d, use the isogenous curve with
a=-1,d=121665 over the same field.

> We're going to need a hash, too. I suggest that we should use one of
> the new hash algorithms that came out of the SHA-3 competition. All
> the finalists have something to recommend them (I really like Skein
> and BLAKE myself):

BLAKE2 is better than BLAKE.

> but the least controversial in my eyes, and so the
> one I'd on consideration suggest, is Keccak, given it was the winner
> and thus has the additional backing of being SHA-3. (I can see ways
> its particular attributes might prove helpful, too.)

Because NSA wants other people to rely on Keccak?  Really?

I can see advantages to using a sponge, but “NSA wants us to eat it”
has never been a good argument.

Robert Ransom