Re: [Cfrg] revised requirements for new curves

Michael Hamburg <> Mon, 08 September 2014 19:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9A1EB1A02D4 for <>; Mon, 8 Sep 2014 12:16:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.555
X-Spam-Level: *
X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jEBlf6ImUpfg for <>; Mon, 8 Sep 2014 12:16:43 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD5811A02C1 for <>; Mon, 8 Sep 2014 12:16:43 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 33C593AA27; Mon, 8 Sep 2014 12:13:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1410203625; bh=XhF3YEEnbqHf9I5Fg3SdvEN9HA63Rcj8ThL4oY+7CF0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=A78UMo28+QcSjYjtuOqFUJjO8qpNPLdb4DVL44u+CAaVeOcqgYtDBjjLfJ1T5DWXs IV9MLSTj+mvNasrNi38CyoSXHoQ0wayWbKFfaZ5C1YoxzIxyZX9sz4/2CH6Kn5ojV5 Lb6NH/u1UVpyPX3OdSheRu++k3RkG5vdsYrmI5sY=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1973.6\))
From: Michael Hamburg <>
In-Reply-To: <>
Date: Mon, 08 Sep 2014 12:16:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "D. J. Bernstein" <>
X-Mailer: Apple Mail (2.1973.6)
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: Mon, 08 Sep 2014 19:16:44 -0000

> On Sep 8, 2014, at 11:36 AM, D. J. Bernstein <> wrote:
> I have two clarification questions regarding SE6:
>> SE6. Required: the selected curves should provide levels of security
>> that match to a good approximation 128-bit, 192-bit and 256-bit
>> security levels, as these levels are currently commonly understood in
>> the wider security community. [NC]
> Background for question 1: E-521 was proposed by three teams
> independently. It appears to be faster on typical platforms than
> Microsoft's 2^512-569, despite the higher security level. It's also
> supported by various arguments from other people, such as "a lot of
> effort has gone into optimization of modular reduction for the NIST
> primes". E-521 reuses the NIST P-521 prime, the only NIST prime that's
> immune to Adam Langley's "What a difference a prime makes" critique.
> Question 1: Does SE6 formally exclude E-521 as being above the "commonly
> understood" 256-bit security level?
> Background for question 2: There are also proposals for faster 414-bit
> and 448-bit curves. This intermediate range is backed by a variety of
> arguments from a variety of people: e.g., clear improvements over the
> larger option in Suite B (NIST P-384 with AES-256); deployment by Silent
> Circle; and the argument "What benefit do you derive from including a
> stronger algorithm in a chain made of weaker algorithms?" combined with
> undisputed evaluations of the AES-256 security level.
> Question 2: Does SE6 formally exclude Curve41417 etc. as being above the
> "commonly understood" 192-bit security level but below the "commonly
> understood" 256-bit security level?
> —Dan

I believe that Kenny’s "at most 4 bits either way for Pollard rho” clarification is calculated to allow Curve25519, E-521 and shortened primes like ed-510-mont; but to formally exclude Curve41417, Ed448-Goldilocks and Ed480-Ridinghood.

— Mike