Re: [Cfrg] Self-correction on mismatched security ... RE: Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)

[Andy Lutomirski <[e-mail]>]

On Thu, Feb 26, 2015 at 1:55 PM, Dan Brown <[e-mail]> wrote:
>
>> -----Original Message-----
>> From: Dan Brown
>>
>> Though I voted above on 448 and 480 as acceptable, just to be clear, we
>> should not label them as providing "256-bit security" and ___not use___ them with
>> AES-256, until we solidify accounting arguments such compatibility, such as:
>
> To correct and clarify myself on the ___underscored point above___ (thanks to an off-list reply):
>
> There's no major problem per se using these smaller curves with AES-256.  (Isn't Suite B even more extreme in that regard?)  It's mainly that one ought not to overstate that the combination as providing 256-bit security.  For example, TLS cipher suite names with AES only mention the AES key size, which may be just fine for the sake of specification, but this number is potentially subject to misunderstanding as describing the overall security level.  So, a mismatch generally risks being confusing or misleading.  If you believe that 256-bit security is excessive, then you may also think that such confusion is all moot, and matching higher security levels is just more excessiveness.  If you believe that 256-bit security adds value, whatever that is, then surely you would not want to mislead anybody about it, at least not in a way that could be checked in a couple minutes.

If, on the other hand, you believe that 256-bit AES is a good idea
because it provides substantially better resistance against batch
attacks, then you would be quite happy with a WF ~ 2^128 curve and
AES-256.

I might go so far as to argue that *no* new protocols should use
symmetric ciphers with keys shorter than 256 bits for encryption.

--Andy