Re: [Cfrg] Safecurves draft

Watson Ladd <watsonbladd@gmail.com> Thu, 09 January 2014 22:25 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 79B5E1A1F7C for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 14:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 yh1OpvNbZBYa for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 14:25:55 -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 A0A061A1F71 for <cfrg@irtf.org>; Thu, 9 Jan 2014 14:25:55 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id t60so3362652wes.18 for <cfrg@irtf.org>; Thu, 09 Jan 2014 14:25:45 -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=VjA4MMc03lpxABliS/F7jJgCL+LZwY40IuLyODDIR5w=; b=KHZQak1gq3BnHss2TEN3cWdFafkFqdq6GCw99q9QcoEiSstBNPfAsmXCj1rqqZ3IF2 /Io7qg2UkzSsceiqrdgTf0y4l4iyKSaXmBPRhbyxPTCZhaaydR0EN0R1w9GuBKj02YYW HUUp/j5AKVc6ykueRXh7itxvpiX/sk+Ugf/XngrHwlH/rpAJHE/f7xqb5b4U43W7IjKJ Gxo0MBpehFI8RtI0do536Elk6egaui7cO7OLDZH0AzhjcFlGy5kVFkq9sA8tfVnqxV4r 14BlRtu82kIQCXntlaVABTZxwr952wfQMXF/MehZUeGiElWixrYXh6K+wBS399ATThzj r/DA==
MIME-Version: 1.0
X-Received: by 10.180.86.9 with SMTP id l9mr5485471wiz.20.1389306345469; Thu, 09 Jan 2014 14:25:45 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 9 Jan 2014 14:25:45 -0800 (PST)
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B7ED7266@SC-VEXCH2.marvell.com>
References: <CACsn0cn4paZTmeVExn+na0MwzdvSn+MF_bmyRZ869pJrWb_8Bg@mail.gmail.com> <52CF1634.6000300@akr.io> <7BAC95F5A7E67643AAFB2C31BEE662D018B7ED7266@SC-VEXCH2.marvell.com>
Date: Thu, 9 Jan 2014 14:25:45 -0800
Message-ID: <CACsn0cmz24Zx9isD=1e-KmkjSazLhk+B7PJOBhJvnttUN5ppiw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] 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 22:25:58 -0000

On Thu, Jan 9, 2014 at 2:10 PM, Paul Lambert <paul@marvell.com> wrote:
> Hi Alyssa,
>
>> On 09/01/2014 14:42, Watson Ladd wrote:
>> > The naming issue is fine: we can say "the safecurve Mxxx has been
>> > found to be unsafe" without risk of being misunderstood.
>>
>> I have to say, on reflection I'm definitely leaning more towards
>> calling the group of curves/IANA registry something else myself.
>>
>> "SafeCurves" is the set of criteria and verifiable vetting process by
>> which djb and Tanja are trying to define safe curves to use: fair
>> enough, keep the reference under that name, they picked it.
>>
>> As Bodo points out, it's _not_ really a collective name for the curves
>> that made it through that process. (Although it's tempting to use it as
>> one, there really isn't one.) As Jon and Paul and Johannes Merkle and
>> others have pointed out, if we did name the registry/RFC that, we're
>> risk looking a bit naïve (and dangerously misleading) at least in a
>> decade, or two, or whenever, when QC eventually bears fruit or
>> something similar happens.
>>
>> If “SafeCurves” risks being confusing, we need another name. …I have no
>> idea. They're next-generation elliptic curves (NGEC?), now that we've
>> found better curve forms than short Weierstrass, but I think "Next-
>> Generation" always sounds a bit silly when it's the current one, or
>> especially when it's the previous one. We may just as well use a
>> catchy, arbitrary name… “Ellipsis”, maybe?
>
> Good points.
> Perhaps if we look at the full collection of curves as a curve catalog,
> we are simply adding two more classes of curves.
>
> There would be some value in comparing the attributes of all curves if
> we treat them as a full set versus old and new.
>
> It also happens that the new curves are using Edwards and Montgomery
> equations.  For an RFC for just these new curves we could just refer
> To these terms - "Edwards and Montgomery Curves for Elliptic Curve Cryptography"
> or something similar ...

RTFD: It is titled simply "Additional Curves for IETF Protocols" and
has been since the beginning.
Safecurves is simply part of the filename with minimal semantic
import. I changed the registry name
in version 01.

Anyway, I'll upload a third revision sometime that addresses some of
the more substantive issues that have been
raised, such as a desire for canonical representations.

A lot of the issues that have been raised are readily resolvable with
additional drafts, should they be necessary, such
as a systemic catalog of all curves. If this really is the worst
problem you have with the draft, I think we're done.

>
>> As far as the names of the individual curves: while a systematic naming
>> scheme is tempting, which is why I raised it, counterbalancing that are
>> that people are actually using these curves _right now_ in the wild:
>> adding new names for them might just serve to confuse everyone. Not
>> everyone's waiting for our informational RFC, after all:
>> people need fast strong crypto badly right now, the routines are
>> already available, and they're getting used. All we're really doing,
>> perhaps, is documenting it consistently as a starting point for their
>> adoption in internet standard protocols like TLS, DNSSEC, IPsec, PKIX
>> and so on.
> This need not be an issue if the new names are clearly distinguishable
> and mapped to the old names.  For example: 'secp256r1' is identical to
> the later 'nistP521'
>
> I suggest that we reuse a similar nomenclature.  It would make the new curves
> look like equals in notation, provide a consistent nomenclature,
> And the postfix 'r1', 'r2' notation is handy for new parameters or generator
> points in the same curve/field.
>
> Proposal:
>  - first four characters define the curve type/equation/math/etc
>  - next 3 or more numbers are the field size
>  - next characters carry an 'r' followed by a revision indication
>
> curve3617 -> edwp414r1
>
>
>>
>> So maybe just stick with the names their respective creators gave them
>> (dropping the caps and dashes as I suggested so command lines and
>> config files don't hate us forever): curve1174, curve25519, curve3617,
>> e511, m521, …
>>
>>
>> On 09/01/2014 09:27, Manuel Pégourié-Gonnard wrote:
>> > While at it, we should also document the requirements for private
>> > keys, which are different from the way they are usually chosen for
>> > short Weierstrass curves.
>>
>> Good call.
>>
>>
>> On 09/01/2014 20:01, Paul Lambert wrote:
>> >> [draft doesn't specify encoding]
>> > Wrong answer — we need interoperability of public key representation
>> > Since a key may be used in multiple applications.
>>
>> As above, given they're already in-the-wild, and we're just documenting
>> them, I'm inclined to just say, use the representation specified in the
>> papers already in the wild, and implemented in the software already in
>> the wild. Done. Time for tea.
> Better answer ... but the representation needs to be documented.
>
> Paul
>>
>> I note [draft-josefsson-tls-curve25519-02] goes with big-endian instead
>> of little-endian, essentially because TLS usually uses big-endian for
>> bignums. I'm probably going to go and comment against that decision,
>> because the paper and every implementation already out there uses
>> little-endian: in a sense, that decision's been made for us (and big-
>> endian lost the commonness fight some time ago)?
>>
>> - --
>> /akr
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQIcBAEBCgAGBQJSzxYzAAoJEOyEjtkWi2t6HfUP/iS0t44KYkNVJIooNhTOztZr
>> 9SBPHXX7DSKzWyV5ZOZ4GtMJsPsRW74tyPZT1VniHG9ZQijdQVa59Kyadse0UKwM
>> chv6Qq2atUq553VKNL7XGQdMjmPSRKuNjgPajynl7Aq096zp+2KZkObfHM/fJqAo
>> l9BHym/ieTzZUJYt1n4AEPz3awEN0EYHZeQ4ABz+zHCguoRYO15UPbWWgWYz16An
>> qXrr4Bsxs8cyioIDnVbnSWDrmfcMe2wAu/0flxgdBJMrrE5/vKmVCl2c16nBtyVx
>> Ox41WcnY5ltj56x4a+q8ko7oSxjRlyV1PsUft+8PLYlpIzMFqE6WOAbd1Igvz+XM
>> 3wPXKuSnMS6yKXryJh+ju1y+v1SERmOdRnxu5Mbu3HqoYbEmMW265AMqxTn/bDPK
>> dKIzgXN+z6t3t6xeA04C3TN/wTKpMJeUL+zau+HFti4Yd5bfIy7YpfGc7moiUC4K
>> RcPxBHS56ebYPNKEi9FncRDUts8OgT8nFsiUt+0MjN+Wz9vdgG5KB9tsDGhTBGnR
>> tG2OYKU0FfIMnICfIoM4Goa0Vs3N8a11Scii0v6QCfABaGDH3f2Zc1AEbCYei1yT
>> sByseeFB6SaSesOkOxWx1dTa4pI9LXmRYXPhhjkcKq8eF0zJNMsKb3a6NsCMZLwC
>> cbtmmLqAzgIAassFudKN
>> =Avz3
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> 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