Re: [Cfrg] revised requirements for new curves

[Michael Hamburg <[e-mail]>]

> On Sep 8, 2014, at 11:36 AM, D. J. Bernstein <[e-mail]> 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