Re: [TLS] Comparative cipher suite strengths

[Robert Relyea <[e-mail]>]

Peter Gutmann wrote:
> [e-mail] writes:
>
>   
>> Therefore, in my mind, they are getting a false sense of security from using
>> AES-256 as the underlying strength of the whole TLS session is determined by
>> the weakest point - in this case the 1024 bit RSA keys, which NIST state to
>> be equivalent to "80-bits" [when compared to a symmetric cipher I guess].
>>     
>
> They're not getting any sense of security at all.  They initially wanted a
> cipher with 128-bit encryption, because everyone knows that you have to have
> 128 bits to be Good.  AES encryption has the required 128 thingies, so they
> went with that.
>
> Then someone pointed out that there's a version of AES with 256 thingies
> instead of 128, and if 128 is Good then 256 must be even Gooder.  So the
> requirement was changed to use AES with 256 thingies.
>
> If there was an AES with 397 thingies they'd go with that instead, because
> it's obvious that that one's ever Gooderer than the one with 256 thingies.
>   
So there is a method behind the AES-256 bit madness, and can see it in 
the cipher suites that NIST specifies.

As Carl has found (and most on this list is familiar with), NIST has 
standardized it's 'strength' specification in terms of symmetric key 
algorithm, which is why he matched AES-256 with a 15K bit RSA key.

NIST also defines strengths for various security levels. 128 bits is the 
minimum for Secret, 192 is the minimum for Top Secret. These numbers are 
both chosen to be more than known foreign governments and agencies are 
likely to be able to crack (presumably including a generous safety factor).

In addition to security levels, NIST also defines a set of cipher suites 
for these levels:

Secret: AES-128, ECC-256 prime, SHA-256
Top Secret: AES-256, ECC 384 prime, SHA-384

Note that AES-256 has a bigger key than required.  NIST specified 
AES-256 because it was already the same speed as AES-192. I don't know 
why they didn't specify SHA-512 over SHA-384 (which has the same 
characteristics).

The upshot is even NIST, using top secret doesn't need 256 bits. It's 
just the easiest way to meet their 192 bit requirement. Also not that 
AES-128 is considered sufficient for the US government to encode  Secret 
information. For practical and commercial use, it's still overkill. 80- 
100 bits is still sufficient for now (though moving toward 100 bits is 
probably prudent).

So you need to go back to your customer and find out what their real key 
strength need is. If your customer needs 192 bits, you probably want to 
move toward ECC ciphers (If you customer's AES-256 is coming from a NIST 
Suite-B requirement, then you'll need to move there anyway). Otherwise 
you are looking at a 7K bit RSA key to meet that requirement.

If you aren't talking to a Suite-B customer, then the info you are 
getting from this list is probably correct "AES-256 sounds strong, might 
as well go there" ignoring the fact that even at AES-128 your weak link 
is RSA (unless you use a 3K key).

bob