128 bit Key Length?


#1

Why is the key length 128 and not 256 bit or larger?


#2

2048-bit and above RSA keys are acceptable.

128 or 256 is about symmetric encryption not related to certificates, and 128 can be considered even more secure than 256 for several reasons.


#3

Interesting. Do you know where can I read about those reasons?


#4

This, for example: https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

Also, forcing 256 can results in bad UX for Chrome users. If you are really going to support 256 only, at least make sure you support CHACHA20_POLY1305. But you should also support 128 to provide more secure connections to Firefox users.


#5

Wiki had this to say on AES Key length: “The Advanced Encryption Standard published in 2001 uses a key sizes of 128 bits, 196 or 256 bits. Many observers consider 128 bits sufficient for the foreseeable future for symmetric algorithms of AES’s quality until quantum computer]s become available.[citation needed] However, as of 2015, the U.S. National Security Agency has issued guidance that it plans to switch to quantum computing resistant algorithms and now requires 256-bit AES keys for data classified up to Top Secret.”


#6

if it’s truly secure I have no qualms about sticking with 128.


#7

AES-128 should be quite secure for the near future. There are weaknesses in AES-256, as pointed out by Mr. Schneier, but that is still a bit more secure than AES-128. It’s just not as secure as it could be given the larger key size.

tl;dr Use of AES-128 is fine unless you have a good reason not to.


#8

thanks for the clarification. also fellow anime fan I see :laughing:


#9

Hi i think that many people here only see the rating on sslabs (which you certainly knew very well) and go to AES256-CBC instead of AES128-GCM only to get better rating. And i think this was discussed in length on your site.


#10

The funny thing is you can get a good score if you use HSTS with a long duration and still support older ciphers. Heck, I’m still supporting TLS_RSA_WITH_3DES_EDE_CBC_SHA and get an A+.


#11

Is HSTS something easily supported by Let’s Encrypt or is it more non-trivial?


#12

HSTS doesn’t have anything to do with the certificate. It’s just an additional header to force HTTPS.


#13

For the curious: HTTP Strict Transport Security


#14

I’m missing the whole CBC/GCM issue as a whole in the aforementioned papers… Yes, CBC has flaws and therefore you’re better off with 128 bits GCM… But what about 256 bits AES-GCM? Does it still have the flaws mentioned in the papers?


#15

The attack is against AES256 independent on the chain/blocking mode.
So yes it work against AES256-GCM too.


#16

I think the main takeaway is that there isn’t good reason to disable AES128, and you might as well keep it if you’re going to allow AES256 too.


#17

That just sucks :frowning: Luckily it’s not the AES256-implementation currently in use (with its 14 rounds) which is vulnerable at the moment… In any case, the There are three reasons not to panic-part eases me enough… I don’t see the need for devaluating AES256-GCM in favor of AES128-GCM because of the aformentioned attacks.


#18

There’s no reason to not offer AES128 at this time either.


#19

No, ofcourse not :smile:

In fact, doing so would probably be very stupid, as Chromium doesn’t support AES256-GCM… So if your server doesn’t understand Chacha20-Poly1305, you’ll be left with sucky CBC ciphers… :stuck_out_tongue: