Re: [Cfrg] Chopping out curves

Alyssa Rowan <> Fri, 17 January 2014 18:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A72791A1F3D for <>; Fri, 17 Jan 2014 10:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9hO6ludkjisj for <>; Fri, 17 Jan 2014 10:58:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0A71D1ADF78 for <>; Fri, 17 Jan 2014 10:58:19 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 5ABE76031B for <>; Fri, 17 Jan 2014 18:58:06 +0000 (GMT)
Message-ID: <>
Date: Fri, 17 Jan 2014 18:58:12 +0000
From: Alyssa Rowan <>
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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 18:58:23 -0000

Hash: SHA512

On 17/01/2014 14:33, Robert Ransom wrote:
> Watson Ladd actually chose a point with small Edwards-form x, not 
> small Edwards-form y. […] ‘T25519’ is isomorphic to Curve25519, so 
> any non-identity group element of odd order on T25519 generates the
> same group as the standard basepoint of Curve25519 (and has the 
> same order).

Ah, thankyou. I missed that (and had mistakenly assumed he'd go for
small y to match the Edwards curves).

Clearly, I haven't had enough tea today!

On 17/01/2014 14:33, Robert Ransom wrote:
> There is no benefit to choosing a new basepoint, but there's also 
> no benefit to using ‘T25519’ instead of the (more efficient) form 
> specified for Ed25519.

On 17/01/2014 15:17, Watson Ladd wrote:
> On reflection the a=-1, d=-121665/121666 form saves an an
> addition, but the multiplication is by a bigger number in the
> complete form. Anyway, I don't have strong thoughts on the matter.

Well then, there's little or no benefit in specifying a new form when
we already have the Ed25519 parameters ready-made and people already
have routines working with it?

On 17/01/2014 14:33, Robert Ransom wrote:
>> I have a strong preference for throwing out T25519 and using 
>> Ed25519 with its standard basepoint.

On 17/01/2014 15:17, Watson Ladd wrote:
> I'll follow that preference, but ugh, the number in front of
> x^2y^2 is big.

If it doesn't really have a performance impact in practice, it's no
big deal.

Ed25519 it seems to be, then. Though, that said, the name might be
confusing. Maybe we'd better call that form something else.

Perhaps: 'te25519', for Twisted Edwards (2^255)-19?

(Deliberately referring to the curve names in lower-case. Thinking
ahead to when people put these things on command-lines or config files
and argue about capitalisation; none of the other curves in IETF
protocols get capitals.)

• If we called it 't25519', people might confuse it with the one in the
  draft here.

• But if we call it 'Ed25519', people might confuse it with the whole
  Ed25519 signature scheme.

  (Sure it's used _in_ that signature scheme, although it seems likely
  to me at this stage that we might be heading more in the general
  direction of a cleaner, fresher version which works with te25519,
  curve3617 and e521, and quite possibly uses a new hash. Demand seems
  stronger for curve25519 ECDHE first, however.)

- --