Re: [Cfrg] Fwd: Re: Safecurves draft

Robert Ransom <rransom.8774@gmail.com> Thu, 09 January 2014 09:50 UTC

Return-Path: <rransom.8774@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83AD1AE1F4 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 01:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbpn1h2lSS3K for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 01:50:59 -0800 (PST)
Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id D422D1AE1F3 for <cfrg@irtf.org>; Thu, 9 Jan 2014 01:50:58 -0800 (PST)
Received: by mail-qa0-f49.google.com with SMTP id w8so1347769qac.22 for <cfrg@irtf.org>; Thu, 09 Jan 2014 01:50:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.49.94.177 with SMTP id dd17mr5663543qeb.14.1389261049039; Thu, 09 Jan 2014 01:50:49 -0800 (PST)
Received: by 10.229.181.132 with HTTP; Thu, 9 Jan 2014 01:50:48 -0800 (PST)
In-Reply-To: <52CE6B92.4030504@elzevir.fr>
References: <52CE59C1.6020500@akr.io> <52CE59F4.8050205@akr.io> <52CE6B92.4030504@elzevir.fr>
Date: Thu, 9 Jan 2014 01:50:48 -0800
Message-ID: <CABqy+srwc1xTkYfLB+DYPkNDNQdDHLdYdw+BWBxuV4ECY-zs=Q@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= <mpg@elzevir.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Fwd: Re: Safecurves draft
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 09:51:00 -0000

On 1/9/14, Manuel Pégourié-Gonnard <mpg@elzevir.fr> 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
Curve25519.

> 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