Re: [Cfrg] Safecurves draft

"Dan Harkins" <> Wed, 08 January 2014 20:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 27CA31AE1A4 for <>; Wed, 8 Jan 2014 12:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K05Wp1UegAyG for <>; Wed, 8 Jan 2014 12:29:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E61FF1AE18F for <>; Wed, 8 Jan 2014 12:29:38 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 9A955A888012; Wed, 8 Jan 2014 12:29:29 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Wed, 8 Jan 2014 12:29:29 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
Date: Wed, 08 Jan 2014 12:29:29 -0800
From: Dan Harkins <>
To: Watson Ladd <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "" <>
Subject: Re: [Cfrg] Safecurves draft
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: Wed, 08 Jan 2014 20:29:41 -0000

On Wed, January 8, 2014 9:58 am, Watson Ladd wrote:
> On Wed, Jan 8, 2014 at 9:21 AM, Stephen Farrell
> <> wrote:
>> On 01/08/2014 05:11 PM, Watson Ladd wrote:
>>> Dear all,
>>> draft-ladd-safecurves contains the Safecurves with orders
>>> 2^255+\epsilon and higher.
>>> I forgot to update the TOC, but that shouldn't stop the substantive
>>> conversation.
>>> Does anyone object to these curves being approved for IETF standard
>>> body use/typos/general nastiness?
>> No objection, but there's maybe some checking to be done
>> before we're ready to push the button.
> Absolutely! Please double check I didn't make any typos, and if you have
> MAGMA access, redo the verifications. This goes for everyone. The more
> eyeballs
> on this, the less chance we make a bad mistake. comes
> with
> a script to redo everything.
> Also, if anyone knows something that DJB and Tanja Lange do not, please
> tell us!
>> One thing though is that rfc 3526 [1] is standards track
>> so if there's a reason for that (and there may or may not
>> be;-) then we might want these to be the same which'd
>> mean not doing 'em in cfrg. That can be figured out later
>> though.
> I have no opinions about how this gets to from draft to RFC.

  Which is good because the process from draft to RFC is already
well-defined. It's on the IETF web site, check it out!

> I understand there are many channels, and
> someone will have to pick one.

  And that someone would be you!

  While it's certainly useful to get these curves defined in an IETF
document, getting them used by any protocol will require some
more work from you. You should get OIDs defined for each of
them if they don't exist already. You should write up separate
drafts for inclusion of these curves into the protocols' various
IANA-managed repositories-- yes, sadly there are many. And
for protocols which allow for in-line passing of complete
domain parameter sets (like TLS) you'll need to modify the
data structure used (doesn't look like these could be used with
the "explicit_prime" ECCurveType, for instance).

  On the plus side, for the most part you can just follow the path
blazed by the brainpool folks, just follow what they did.

  Welcome to the tedious world of sausage making, don't mind
the blood on your hands, you get used to it.