Recently we had a question about why our SaaS system (my.alfresco.com) seemed to be preferring AES-128 ciphers for SSL/TLS rather than AES-256.
This was a good question that led me down some interesting paths which I thought I'd share.
Firstly, this system is hosted in Amazon Web Services and we follow their best practice for ELB ciphers. These are detailed here https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html￼
We are using the TLS-1-1-2017-01 policy which is the most modern version that we can use and still retain backwards compatibility for the browsers that are on our supported list.
The list of ciphers in that list is Amazon's recommended order that cipher negotiation should happen. It's interesting to see that AES-128 is above AES-256 in that list, which is why my.alfresco.com is offering them first.
This is also in line with Mozilla's guidance on the order of ciphers for their intermediate compatibility https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29 where AES-128 comes before AES-256. Intermediate compatibility is their best level that still supports a wide range of clients.
It is widely believed in the cryptographic community that AES-256 is a weaker algorithm than AES-128. As described here https://www.schneier.com/blog/archives/2009/07/another_new_aes.html, there are known attacks against AES-256. It is still almost completely impractical to make use of those attacks, but interesting that they don't apply to AES-128.
The only known attack against AES-128 which is faster than brute force attempts of the key is described here https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks. As described by the author this would need more storage than all of the data stored in all of the computers in the world in 2016 to make an attack, so it can be described as impractical!
The Snowdon docs say that the NSA are working on new attacks on AES( https://www.theverge.com/2014/12/28/7458159/encryption-standards-the-nsa-cant-crack-pgp-tor-otr-snowden ) but we can't take any real consideration of that until such a time as the attacks become public.
As an aside, with AWS's defined order of ciphers, we are still getting an A+ score against SSLlabs. https://www.ssllabs.com/ssltest/analyze.html?d=my.alfresco.com&hideResults=on
Also, according to stackexchange (so it must be true ) there's a 40% CPU overhead on AES-256 against AES-128, which is quite a performance and cost overhead. https://crypto.stackexchange.com/questions/20/what-are-the-practical-differences-between-256-bit-192-bit-and-128-bit-aes-enc/23#23
So to summarise, AES-128 has fewer known attacks than AES-256, is impractical to attack/brute force (as far as we know) and is less computationally intensive than AES-256, so it's a valid to use in an SSL/TLS cipher suite.