Re: [Cfrg] Safecurves draft

Robert Ransom <> Thu, 09 January 2014 14:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C97D71AE2E3 for <>; Thu, 9 Jan 2014 06:34:30 -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 73HtVHypg3j1 for <>; Thu, 9 Jan 2014 06:34:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::232]) by (Postfix) with ESMTP id E23E41AE30F for <>; Thu, 9 Jan 2014 06:34:22 -0800 (PST)
Received: by with SMTP id cm18so1660140qab.9 for <>; Thu, 09 Jan 2014 06:34:13 -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=5NRHS7UKfMiuqctPmm4DCanAsE1GFnHOsA2qu0PbF9M=; b=xx7nwyk7CFZjm+cwUB1v/KecEaxoUJZd31nFgTDGNgL3CuYusfNCy+8TDcL2NZ2gwc 1XONKy0C6nwUkaXcERE9TXKztVsRwMTebDsXT/WPLP6f0wQ3No8pwM+GZO6pTBChS40s ne4gp1a+2CuvVbFRgUbwxjmwiIQ3VYGBejULrCyxfMS0k5nqiAhIL+CmSunEbxRY1GJJ EjnnmHvpBv+Khd6bggyiisv1yifbqG5z+lTv1Me2bTX0c6JACTN0GoGhjNvhECZmbrR5 NSxrrTGjfsoN5m3P/sN3ma9jdu8rwjgl+IQoy29Ol2LanVKUGvQg+0ywQ0I0iMO9Cl5D OZDA==
MIME-Version: 1.0
X-Received: by with SMTP id r1mr8359584qej.4.1389278053266; Thu, 09 Jan 2014 06:34:13 -0800 (PST)
Received: by with HTTP; Thu, 9 Jan 2014 06:34:13 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 09 Jan 2014 06:34:13 -0800
Message-ID: <>
From: Robert Ransom <>
To: Bodo Moeller <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Cfrg] 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 14:34:31 -0000

On 1/9/14, Bodo Moeller <> wrote:
> Robert Ransom <>:
>> On 1/9/14, Bodo Moeller <> wrote:
>> > In that context, given that the name
>> > "Curve25519" is already overloaded, and that we probably should make
>> > the
>> > Edwards representation available for DH too (in addition to EdDSA),
>> No.  Montgomery-form variable-base single-scalar multiplication takes
>> 5M+4S per scalar bit; Edwards-form doublings alone (in ‘extended
>> coordinates with a=-1’) are 4M+4S (or 3M+4S if the output will only be
>> used as input to another doubling).
> As pointed out by Section 6 in,
> sliding-window multiplication using the Edwards form can be faster than
> 5M+4S per scalar bit for this curve (although that's probably no longer
> true if you want a constant-time implementation -- while the non-sliding
> window approach in Section 8 doesn't seem optimal because it's not making
> use of signed windows, I don't think the extra savings are sufficient to
> beat the Montgomery ladder).  More importantly, if you have a *fixed* base
> (which is very relevant for ephemeral ECDH), with appropriate fixed
> precomputation you won't need any double operations at all: so the total
> time for one fixed-base single-scalar multiplication and one variable-base
> signal-scalar multiplication as used in ECDH can be less than with the
> Montgomery ladder, even if you want constant time with no secret-dependent
> branches.  If you have severe space constraints, then an approach that
> involves a few hundred precomputed points is not for you, but in many
> typical scenarios this is not an issue at all.
> So while the Montgomery-form Curve25519 certainly has its use, allowing
> applications to negotiate a different form for ECDH would be beneficial.

Even if the party which generates a public key uses Edwards-form
points internally for that operation, whoever generates the key can
put it into Montgomery form for free before scaling, whereas whoever
receives it would need to perform an extra coordinate inversion in
order to convert from Edwards form to affine Montgomery form.  (Over
an implementation-friendly coordinate field, projective-base
Montgomery-form point multiplication is always slower than scaling
followed by affine-base Montgomery-form point multiplication.)

I really don't see any benefit to transmitting an Edwards-form point for ECDH.

Robert Ransom