Re: [Cfrg] Brazil Curves -> Re: Safecurves draft redux

Watson Ladd <> Mon, 20 January 2014 22:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 241E61A024D for <>; Mon, 20 Jan 2014 14:28:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9CXeglfl8E3q for <>; Mon, 20 Jan 2014 14:28:05 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22a]) by (Postfix) with ESMTP id D257C1A01F2 for <>; Mon, 20 Jan 2014 14:28:04 -0800 (PST)
Received: by with SMTP id l18so4406051wgh.5 for <>; Mon, 20 Jan 2014 14:28:04 -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=rXyYR8IvaxR9NfMamOJRx0kC6nh9w/2cYSS3ySrKPVU=; b=bT+EAU5OTOxOdF5GoQ1qbeDjf1GVNzNiFanSVvvD2KThll868Ms3tZAXpMb6gx0pbZ FHHY0m7EuMryVvoguSbBc9xrZYcluXrI8jT3LuOSspMhLVRDTR80eJ0zyahhdrNTPkkO 2dSa32GM+694t+pwKo7yUU8Jvwimmg9FK5Tx0JB45SvfiQqd9jxp7P5GfnEbppY7BCdx wGclz6I0r+QMzEaaL5Y/k/ROWjTTiBSK0rU2A92u733t9Zmb98nlO0I+TIZA5rJ/2I3F ctBpY35LfaTIBFKJny5anKna21hDFoabXbt8zivVjw/KnHE12Ffut8UVar+uaZ369wQB KdIA==
MIME-Version: 1.0
X-Received: by with SMTP id b3mr11881947wie.20.1390256884231; Mon, 20 Jan 2014 14:28:04 -0800 (PST)
Received: by with HTTP; Mon, 20 Jan 2014 14:28:04 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 20 Jan 2014 14:28:04 -0800
Message-ID: <>
From: Watson Ladd <>
To: Paul Lambert <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Cfrg] Brazil Curves -> Re: Safecurves draft redux
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: Mon, 20 Jan 2014 22:28:07 -0000

On Mon, Jan 20, 2014 at 12:11 PM, Paul Lambert <> wrote:
>>The naming issue is fine: we can say "the safecurve Mxxx has been
>>found to be unsafe" without risk of being misunderstood. If there is
>>consensus that we should call the IANA registry something else, say
>>"Chicago curves", I'm not opposed to it.
> More of the curves seem appear to have come from Brazil (not necessarily
> the movie) than Chicago.
> There was a thread on clear naming conventions that has some consensus
> that did not add confusion by creating cute names.  Could we please
> proceed with a consensus based draft.

Naming them E or M then prime description would work. We would also need a
T. So far I've resisted renaming from the SAFECURVES names, but that
will change since
we need to invent some.

As for naming the whole set, that's where Chicago comes in. Brainpool
is certainly not
a cute name, but I doubt the mental images were in the naming process.

We aren't even at a point where I have something I would sent to Last
Call. I have
some edits to make (see TE25519 discussion where I screwed it up),
and with the start
of the semester haven't had time to do this yet.

> I also believe we are rushing too fast on the Œtrimming¹ before we have
> clearly identified and listed the attributes of the curves we have under
> recommend.  A draft list the alternates and attributes seems essential.
> Consensus might then be possible when we can have are more coherent and
> documented review process.

Well, I haven't trimmed anything yet: I just want to have discussion
about how many we should recommend.
As for listing the attributes and identifying them, I think the draft
makes it pretty clear, even it is current state, what
these curves are. Perhaps we need to make more clear that most
implementations of ECC get it wrong. (Even AGL and
I punted when making constant time P256 implementations: we return
errors in some cases where we shouldn't.)

> Also, there is value in having strong recommendations for a few curves
> used for identity/authentication.  There is also value in describing
> alternatives for new protocols that might wish to have some crypto
> diversity.  Documented a larger set with well described properties and
> possible applications would meet both requirements.

All curves avoiding certain known badnesses are the same from a
security standpoint.
They aren't from an efficiency standpoint. if a new protocol wants
diversity, it should avoid
ECC entirely.

As for possible applications, I'm really not sure what we're looking
at here. Given a curve you can get
Schnorr signatures and ECDH on it. That will be in a different
draft/is bog-standard cryptography.

There is a PAKE idea for the new curves that is being developed, but
it still needs to get drafted.

Watson Ladd
> Paul

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin