 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Peter Gutmann wrote:
So there is a method behind the AES-256 bit madness, and can see it in the cipher suites that NIST specifies.carlyoung at keycomm.co.uk 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.
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-384Note 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature