Re: [Cfrg] Fwd: Re: Safecurves draft

Robert Ransom <> Thu, 09 January 2014 09:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D83AD1AE1F4 for <>; Thu, 9 Jan 2014 01:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Status: No, score=-1.45 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qbpn1h2lSS3K for <>; Thu, 9 Jan 2014 01:50:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::231]) by (Postfix) with ESMTP id D422D1AE1F3 for <>; Thu, 9 Jan 2014 01:50:58 -0800 (PST)
Received: by with SMTP id w8so1347769qac.22 for <>; Thu, 09 Jan 2014 01:50:49 -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=wUP0sHj0ZzMr6Io0i10pBkwrywFhkBjyGb7QidPySVc=; b=xwg4sxqBSRrRi/25N7xvoFZ/+HYtJZEIxZsjNuXhQn0aNvB3FO2kLbGL/RLQZYeKf7 bTKJnZle6QNpBGCVMuCqgeB6BZXkWc49GgzmwnkKqLMSvuEO0kmpMWCMBHsiCmIg9XIZ wnJJ1P1Rjrs0bYjdWCCPiqyGURQtB4mXotd/JyhKAi39ITEapNhNv/pdjrLU3Hhnqdap XWgGABf/ZSswlWET+f8uq/YGh5VrxzmjvBLLQHEA/3+AMV03ZzsgZSxZ3wCiwzCADtDp i1y8huyMTGZlQ4VxDcgSb6xgXaeDXDvZXX/8TaMIomL4JCs2CseOmz+vTUbrpRqUgWGh t5UA==
MIME-Version: 1.0
X-Received: by with SMTP id dd17mr5663543qeb.14.1389261049039; Thu, 09 Jan 2014 01:50:49 -0800 (PST)
Received: by with HTTP; Thu, 9 Jan 2014 01:50:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 09 Jan 2014 01:50:48 -0800
Message-ID: <>
From: Robert Ransom <>
To: Manuel Pégourié-Gonnard <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Cfrg] Fwd: Re: Safecurves draft
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: Thu, 09 Jan 2014 09:51:00 -0000

On 1/9/14, Manuel Pégourié-Gonnard <> wrote:
> On 09/01/2014 09:12, Alyssa Rowan wrote:
>> On 08/01/2014 23:50, Watson Ladd wrote:
>>> I don't want to rename curves because that induces consistency
>>> issues.
>> Entirely accepted: I raised it merely as a question. People are
>> already beginning to adopt these curves of their own volition, so
>> changing the names of them could be confusing, yes.
> About names, I'd really like the names to reflect the type of the curve
> (Montgomery or Edwards). This is already the case for other curve families,
> by
> the way. So, Mxxx and Exxx seem great to me. I'd even go so far as to rename
> Curve25519 as M255, but I'm sure there are good reasons to disagree on this
> point.

Remember that Curve25519's parameter is *not* minimal subject to the
constraint of twist security with minimal cofactors -- Dr. Bernstein
considered a slightly more subtle criterion regarding the group orders
too.  Keep that in mind if you try to establish a systematic name for

> While at it, I also think the document should define the curves for each
> type in
> distinct sections. Overall, the goal is that it should be easy for other
> document to define the of just the Montgomery (or just the Edwards) curves
> for
> use in a protocol, and refer to the appropriate section of this draft.

I don't see the benefit of defining both a ‘safe’ Montgomery curve
(for the present definition of “safe”) and a ‘safe’ Edwards curve over
the same coordinate field -- every Edwards curve with minimal
parameter can be used efficiently with Montgomery's formulas.  (The
Montgomery-form parameter becomes the reciprocal of a small integer,
which can be handled as efficiently as a small integer itself.)

(For that matter, I would suggest replacing Curve25519 with the
twisted Edwards curve a=-1, d=121665 over the same field in any new
application or standard.)

I would also recommend highlighting the most efficient curves --
Curve25519 and Curve3617 have especially nice coordinate fields; even
2^521 - 1 is less convenient (the limb arrangement is less regular).

> Take the points list on the frontpage of the safecurves site, for instance
> (numbered by me for convenience).
> 1. Your implementation produces incorrect results for some rare curve
> points.
> 2. Your implementation leaks secret data when the input isn't a curve point.
> 3. Your implementation leaks secret data through branch timing.
> 4. Your implementation leaks secret data through cache timing.

> Overall, of course it's nice that issues 1 and 2 are completely annihilated
> by
> Montgomery and Edwards curves,

Issue 2 is obviated by twist security for single-scalar multiplication
of a Montgomery-form x coordinate.  It remains relevant for any
application which operates on full points (whether transmitted
uncompressed or compressed).

> and to be fair point 4 is a bit easier to
> address
> with these curves too.

Why 4?  The benefit of complete addition formulas is that
implementations don't need to switch to a doubling routine when two
points are equal.  Nothing about SafeCurves makes constant-time table
lookups any easier.

Robert Ransom