Re: [Cfrg] New names for draft-ladd-safecurves

Watson Ladd <watsonbladd@gmail.com> Tue, 21 January 2014 18:34 UTC

Return-Path: <watsonbladd@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 710761A0135 for <cfrg@ietfa.amsl.com>; Tue, 21 Jan 2014 10:34:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 VEx9AgaPEUyZ for <cfrg@ietfa.amsl.com>; Tue, 21 Jan 2014 10:34:45 -0800 (PST)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 43C521A016E for <cfrg@irtf.org>; Tue, 21 Jan 2014 10:34:45 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id t60so8513377wes.32 for <cfrg@irtf.org>; Tue, 21 Jan 2014 10:34:44 -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; bh=u3soiZgt94P5LNsQOhdneeilfnOyPoSLEH/wrGj7ezw=; b=FHf8jx1ogIvO09lL+PqRhfDWecqfrZ3ZfxH4Y0xSiVd7T8yfNly+ZTDh7nT0aY/sJP tvf3/3csUDWDDHlZK95V2V0JX7hlu1Pmigu13H+AoYJookUJdf4XLJ3RL1chSJMUAK0Z NJPANxJfIqqIR+O8R5Ki6q5jbxbYja5zkWHYvLXvEdkiFrIsst9S3CGBpKjNse9CkIDH v+PTi9YSiWJiH3bjoizSSywtM30bI4UYbID9W/NHYmKIQkZdEe5yZTgx+lDNBDNVN9As 64G8QfjA0RQTkets8BuLVmSboTNZNI+vSa9TO30re2gpXaTuCd+j+Nxe1rqGwmmdrrkd Jrdw==
MIME-Version: 1.0
X-Received: by 10.194.92.7 with SMTP id ci7mr3142711wjb.58.1390329284628; Tue, 21 Jan 2014 10:34:44 -0800 (PST)
Received: by 10.194.250.101 with HTTP; Tue, 21 Jan 2014 10:34:44 -0800 (PST)
Received: by 10.194.250.101 with HTTP; Tue, 21 Jan 2014 10:34:44 -0800 (PST)
In-Reply-To: <CF03FB51.2CEE5%paul@marvell.com>
References: <CACsn0ck02mnETBUfuyJjLV9K8Yuiki8_-RG0tVszL8BDhkK27w@mail.gmail.com> <6489F7D3-BF54-416F-94BE-64FD1CFCCB1E@callas.org> <CADMpkc+fxfXL8A21bGKgobKFvHxhQaiCEzROQmX4uH_73bgk1Q@mail.gmail.com> <CACsn0c=yrO5WiqshQ0z-eF+u1boyUYK5OQdr_XORXKTzJ7=KKA@mail.gmail.com> <CF03FB51.2CEE5%paul@marvell.com>
Date: Tue, 21 Jan 2014 10:34:44 -0800
Message-ID: <CACsn0c=n+jdJF3B_BJW8xpsbsJnQD-j9fQh_+ZVW-k9JiydDyg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary=089e0149460221971d04f07f4394
Cc: cfrg@irtf.org, Jon Callas <jon@callas.org>
Subject: Re: [Cfrg] New names for draft-ladd-safecurves
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: Tue, 21 Jan 2014 18:34:50 -0000

On Jan 21, 2014 10:30 AM, "Paul Lambert" <paul@marvell.com> wrote:
>
>
>
> On 1/21/14, 8:33 AM, "Watson Ladd" <watsonbladd@gmail.com> wrote:
>
> >On Tue, Jan 21, 2014 at 7:28 AM, Bodo Moeller <bmoeller@acm.org> wrote:
> >> Jon Callas <jon@callas.org>rg>:
> >>
> >>> I spent time talking to Dan and Tanja this weekend at ShmooCon about
> >>>this
> >>> sort of thing and I think that our agreement was that names like
"Curve
> >>> 255-19" (which covers both Curve25519 and Ed25519) or "Curve 414-17"
> >>>(for
> >>> the curve formerly known as Curve3617) made sense.
>
> Two names would be better to differentiate between a Edwards or Montgomery
> based point representation for the same curve.
>
> WE also are working on the assumption that there are just one curve choice
> for a particular field size. We should provide a extensible naming scheme
> that would allow the later introduction additional options (e.g. Ed255
> would be #1 of that size and flavor).
>
Why would we need these other options? If you have a new curve it needs to
look different to have a speed advantage. The security picture for ECC has
been stable for decades now.

> Paul
>
>
> >
> >My one concern which I've stated before is that we would then need a
> >single wire format for Curve25519 and Ed25519.
> >Robert Ransom's idea (sorry for the hijack) is the following: Suppose
> >Bv^2=u^3+Au^2+u is isogenous to ax^2+y^2=1+dx^2y^2, with the isogenies
> >u=(1+y)/(1-y), v=(1+y)/(1-y)x=ux. Then we represent points as u and
> >the sign of x.
> >
> >A=2(a+d)/(a-d)
> >B=4/(a-d).
> >
> >An implementation using the Montgomery ladder to multiply proceeds as
> >usual, using the fact that A is the reciprocal of a small integer
> >to rewrite the equations. It then reconstructs v (there is a fast
> >formula), and uses that to compute the sign of x. One using the
> >Edwards curves proceeds as usual, then inverts the isogeny to get u,
> >and uses x to get the sign bit.
> >The argument for this is we can specify all our curves in twisted
> >Edwards form with d small, a=+/-1, and life is nice for everyone.
> >Unfortunately Curve25519 doesn't fit this nice pattern, and people
> >want to use that exact curve. This form also involves a bit of extra
> >field math for everyone, even if they are all going to do ECDH or
> >Edwards addition afterwards, and so will want that form anyway. There
> >is also a problem of exceptional cases if a and d are nonsquares
> >modulo p for example.
> >
> >Have I rendered correctly the arguments for and against?
> >>
> >>
> >> Yes, it does. This would fix the single major flaw of Curve25519 --
> >> concatenating base-10 numbers to spell out a tuple just doesn't make
> >>sense
> >> (except as a trap, so that if anyone reads it out as "twenty-five
> >>thousand
> >> ..." you'll know they don't know what they're saying).  I also don't
> >>really
> >> like having whitespace in those names, so I'd prefer "Curve-255-19"
over
> >> "Curve 255-19".
> >>
> >> ("Curve" isn't very descriptive, but I've yet to see a more descriptive
> >>name
> >> for this curve that is actually helpful.)
> >
> >NIST isn't useful either as a prefix, but we live with it.
> >Anyway, my view is whatever people want to call these they can call
> >them, bobo and kiki aside.
> >>
> >> Bodo
> >>
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> Cfrg@irtf.org
> >> http://www.irtf.org/mailman/listinfo/cfrg
> >>
> >
> >
> >
> >--
> >"Those who would give up Essential Liberty to purchase a little
> >Temporary Safety deserve neither  Liberty nor Safety."
> >-- Benjamin Franklin
> >_______________________________________________
> >Cfrg mailing list
> >Cfrg@irtf.org
> >http://www.irtf.org/mailman/listinfo/cfrg
>