Re: [Cfrg] revised requirements for new curves

Michael Hamburg <mike@shiftleft.org> Mon, 08 September 2014 19:16 UTC

Return-Path: <mike@shiftleft.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1EB1A02D4 for <cfrg@ietfa.amsl.com>; Mon, 8 Sep 2014 12:16:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEBlf6ImUpfg for <cfrg@ietfa.amsl.com>; Mon, 8 Sep 2014 12:16:43 -0700 (PDT)
Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5811A02C1 for <cfrg@irtf.org>; Mon, 8 Sep 2014 12:16:43 -0700 (PDT)
Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 33C593AA27; Mon, 8 Sep 2014 12:13:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; 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 <mike@shiftleft.org>
In-Reply-To: <20140908183635.18192.qmail@cr.yp.to>
Date: Mon, 8 Sep 2014 12:16:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4795BDF2-C7E0-430B-84C8-98EC71365DDF@shiftleft.org>
References: <20140908183635.18192.qmail@cr.yp.to>
To: "D. J. Bernstein" <djb@cr.yp.to>
X-Mailer: Apple Mail (2.1973.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/to5MT759TPUMUTMDVZjgaF4x9QM
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] revised requirements for new curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 19:16:44 -0000

> On Sep 8, 2014, at 11:36 AM, D. J. Bernstein <djb@cr.yp.to>; 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.

Cheers,
— Mike