Re: [Cfrg] Fwd: Re: Safecurves draft

Manuel Pégourié-Gonnard <mpg@elzevir.fr> Thu, 09 January 2014 23:42 UTC

Return-Path: <mpg@elzevir.fr>
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 AE5201AD8D8 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 15:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.994
X-Spam-Level:
X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793] 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 MU91mdvzR_oL for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 15:42:11 -0800 (PST)
Received: from mordell.elzevir.fr (unknown [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id CAB461A1F5F for <cfrg@irtf.org>; Thu, 9 Jan 2014 15:42:10 -0800 (PST)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 3C86B161DF; Fri, 10 Jan 2014 00:42:00 +0100 (CET)
Received: from [192.168.0.12] (mna75-11-88-161-199-191.fbx.proxad.net [88.161.199.191]) by thue.elzevir.fr (Postfix) with ESMTPSA id B628B2988A; Fri, 10 Jan 2014 00:41:58 +0100 (CET)
Message-ID: <52CF33C4.3080108@elzevir.fr>
Date: Fri, 10 Jan 2014 00:41:56 +0100
From: Manuel Pégourié-Gonnard <mpg@elzevir.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: Robert Ransom <rransom.8774@gmail.com>
References: <52CE59C1.6020500@akr.io> <52CE59F4.8050205@akr.io> <52CE6B92.4030504@elzevir.fr> <CABqy+srwc1xTkYfLB+DYPkNDNQdDHLdYdw+BWBxuV4ECY-zs=Q@mail.gmail.com> <52CE783C.40504@elzevir.fr> <CABqy+sr6FBz16Le8aRb5gDv5MgW67zJdb-MJrqEjW57t0O390w@mail.gmail.com>
In-Reply-To: <CABqy+sr6FBz16Le8aRb5gDv5MgW67zJdb-MJrqEjW57t0O390w@mail.gmail.com>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
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 23:42:12 -0000

On 09/01/2014 17:38, Robert Ransom wrote:
> On 1/9/14, Manuel Pégourié-Gonnard <mpg@elzevir.fr> wrote:
>> I'm not sure it goes against my argument that the name should reflect the
>> type
>> of the curve. Or did I miss something?
> 
> That's an argument against making curve names appear systematic (e.g.
> “M255”) when they may not be.  (I particularly dislike the naming
> schemes used in the various versions of 2013/647.)
> 
Oh, yes, fair point. Sorry for missing it the first time.

> I guess I have more of a problem with the idea that Montgomery and
> Edwards are two different types of curves at all.  The important fact
> to convey for a SafeCurve is which *part* of the curve one is talking
> about: [...]
> All of this makes good nomenclature for the various curves and
> subcurves and subgroups and subsets both more difficult and more
> important to define properly.
> 
100% agreed.

> A Curve25519 (Montgomery-line ECDH) implementation will generally use
> a ladder with no precomputed table because Montgomery's formulas are
> so much faster that way.
> 
> An Ed25519 (Edwards curve, typically signature-related) implementation
> will generally use either [...]
> 
Right. Since I only implemented the Montgomery version so far, I've got the
nasty habit of thinking mainly about that form.

But, unless I'm mistaken, it seems to me we agree on the main point here: "no
data-dependant branches or memory access" is a property of the implementation,
not of the curves. (And I take back my comment that the curves from safecurves
make the "no data-dependant memory access" part easier.)

Manuel.