Re: [Cfrg] Curves specification possibly complete.

Stephen Farrell <> Wed, 26 August 2015 21:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 453F11B335F for <>; Wed, 26 Aug 2015 14:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BlAJwox0l5sU for <>; Wed, 26 Aug 2015 14:51:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA5E31B3355 for <>; Wed, 26 Aug 2015 14:51:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E8C5BE53; Wed, 26 Aug 2015 22:51:40 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NFyipJyS55si; Wed, 26 Aug 2015 22:51:39 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 00F39BE51; Wed, 26 Aug 2015 22:51:38 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1440625899; bh=Xohj+IwAtZONyjWyfK09frAF7XbxalwO0SJr5f87/dI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=j/q5MluToviDbRj5f4nq8XUQDDARLAdESjmaHRNtk2tibV1/c/Vo1+voHljzgPp55 ZubpzE4blaSyfxHyUaU2VPVact/de7sZgCZxM8gjT2RtG5GL2a/IU91jCvswDXYIkQ SVQYumlwae3f2JQ80ZkScWt67+yAybrBfGsQhc6A=
Message-ID: <>
Date: Wed, 26 Aug 2015 22:51:35 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Adam Langley <>, "" <>
References: <>
In-Reply-To: <>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Cfrg] Curves specification possibly complete.
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, 26 Aug 2015 21:51:43 -0000

Drat! I was half done with -05 and there you go making it better:-)

I've only one substantive comment so far though and some (very
ignorable nits). I hope to get time to read it in more detail but
since that mightn't happen or you may be on -99 before I get to
it, my comments on -05 are below.

I do think this is sufficiently baked to go forward in case that
isn't clear.


Only one substantive comment:

- The (currently missing) security considerations (or somewhere)
should describe why Curve25519 is ok when used in contexts where we'd
otherwise ask for 128 bit strength, (basically because it's close
enough), and also why the 224 bit level is considered a good choice.
There was a lot of debate on the list about that, and I've seen the
issue come up elsewhere so this text will avoid re-litigating that and
should be worthwhile even if it takes a little time to agree.

nitty-nits: (which are ok to ignore)

- title/abstract: we're not including the signature scheme based on
these curves in this document. But we do talk about ECDH.  Shouldn't
that be reflected in the title/abstract?

- intro: wouldn't a reference to RFC6090 be useful as well as or
instead of [SEC1]? 6090 does after all have references to very old
descriptions of ECC.

- intro, para 2: wouldn't it be more accurate to say that these curves
lend themselves to natural constant-time implementations rather than
say that they "support" constant time?

- intro: references for Montgomery and Edwards would be good.  (And
ones suited for implementers, not mathematicians.)

- section 5, para 1: be good to say that the 32 byte output is for
X25519 and the 56 for X448. (Yes, it's obvious but good to be

- section 5, para 2: you start with u[0] and end with u[n] - isn't it
more common to end with u[n-1] there? In this case it doesn't matter
as you don't say n=32 or n=56 but maybe there's a small chance that
might trip up some coder somewhere (though it's hard to see how so
consider this a totally pedantic nit, offered just to see who else
wants to be pedantic:-)

- section 5: the RFC editor will ask if you want "CODE BEGINS" markers
around the python code.

- section 5, last para on p8: you say here it's important to not do a
bad thing, but you don't say (or provide a reference as to) how to
avoid the bad thing.

- I think section 7 could now be placed in an appendix.

- section 7: trace of Frobenius needs a reference, as do MOV degree
and CM discinimant. If the current references explain those then say

- I think this draft should have security considerations that say a
little about good implementations, mainly via reference if possible.

- An RFC6982 "implementation status" section could be useful here as I
guess we don't really want all and sundry writing the code for all
this. Note that that could be useful even if the text doesn't end up
in the RFC - people will find it anyway. (And I think 6982 was wrong
in saying such sections should be deleted before RFC publication.)

To re-iterate - all these nits are just that and I am ok if they are
utterly ignored.