Re: [Cfrg] revised requirements for new curves

Alyssa Rowan <> Sun, 14 September 2014 19:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D6A071A019B for <>; Sun, 14 Sep 2014 12:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Te6ZWoIlC0vM for <>; Sun, 14 Sep 2014 12:20:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D0031A0196 for <>; Sun, 14 Sep 2014 12:20:38 -0700 (PDT)
Message-ID: <>
Date: Sun, 14 Sep 2014 20:20:42 +0100
From: Alyssa Rowan <>
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [Cfrg] revised requirements for new curves
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: Sun, 14 Sep 2014 19:20:40 -0000

Hash: SHA512

On 08/09/2014 11:23, Paterson, Kenny wrote:
> Intellectual Property
> IP1. Required: securely, simply and efficiently implementable
> world-wide under royalty-free licensing terms. [C]
> IP2. Desired: securely, simply and efficiently implementable
> world-wide in a patent-free manner. [RC]

I think it'd be invaluable for potential proposals to have a clear
statement about the patent status of a (secure, simple and efficient)
reference implementation, at least - otherwise, it's hard to know how
we can best evaluate these criteria, particularly alongside PE1 and PE2?

It'd be even more helpful for adoption downstream if those reference
implementations were suitable, and permissable, for wide practical use.

Would a patent search help? Someone recently said to me that elliptic
curve cryptography was a [patent] minefield (albeit less so as some
older patents, such as point-compression, expire) - and if we can
clear, or at the very least map, as much of that minefield as
possible, many potential barriers to adoption could be removed.

On 08/09/2014 15:42, Phillip Hallam-Baker wrote:
> I didn't see consensus that we needed 192 bit curves.
> These seem superfluous to me If I want speed then I will go to 128
>  bits. If I want high assurance I will go to 256. 192 is neither 
> fish nor fowl.
> In a perfect world folk can make fine tuned choices between speed 
> and security but I only have two security levels: paranoid and
> till the sun goes supernova secure level paranoid.

I concur entirely with this, agl's points, and Markulf's.

≈WF128 curves can I think deliver the strong, but very efficient
functions IETF protocols are going to want for cryptography everywhere.

≈WF256 curves can deliver about the best we can probably expect from
elliptic curves, until quantum computers eventually show up and crash
that party. If you want to be extra-careful, and some do, that's the
way to go.

≈WF192 is not a great compromise either way IMHO, especially as there
are no convenient 2^x-n primes with very small n in the immediate
vicinity of 384-bit.

Plus, 2 new curves are easier to specify and implement correctly than
3. (1 is of course easier still - as with agl, if we had to pick one,
I'd pick ≈WF128 - but I'd suggest keeping ≈WF256, too.)

If it's optional, I definitely say drop 192 from requirement SE6. You
don't exactly see people queuing up to use AES-192, do you (or even
SHA-384 for anything but NSA Suite B)?

- --