'SWEET32' 64-Bit Cipher Attack: Legacy Crypto Causing More Troubles For TLS Encryption

Two researchers from the French Institute for Research in Computer Science and Automation (INRIA) achieved a practical collision attack against the legacy 3DES cipher. Only about 1% of websites are vulnerable to the attack, but that 1% includes some important ones such as Ebay.com, Walmart.com, Match.com, and Citrix.com. The attack may also affect some VPN providers that still rely on the 3DES cipher, or other ciphers with 64-bit block sizes (such as Blowfish).

SWEET32 Collision Attack On 64-Bit Block Ciphers

As the name implies, 3DES (or Triple-DES) has a key size that is three times longer than the key for the original DES cipher (168-bit vs. 56-bit). However, 3DES kept the same 64-bit block size, whereas other block ciphers such as AES have moved to at least 128-bit. Threefish, the block cipher designed by Bruce Schneier and Jon Callas, supports block sizes of up to 1024-bit, for example.

In their “SWEET32” paper, the INRIA researchers, Karthikeyan Bhargavan and Gaëtan Leurent, showed that all 64-bit ciphers (not just 3DES, although that’s what they tested) should now be vulnerable to plaintext recovery attacks that work even if the attacker cannot recover the encryption key. The theory behind such attacks has been known for some time, although there hasn’t been a practical attack taking advantage of this cipher weakness yet.

A collision attack against encryption using 64-bit ciphers can happen when around 2^32 bytes of encrypted ciphertext are created. That translates to 32GB of data, which isn’t that much in the context of a TLS-encrypted service from a large company.

Deprecating Vulnerable Ciphersuites More Quickly

The INRIA researchers also argued in their paper that SWEET32 shows once again why it’s a mistake to leave protocols that have known (at least in theory) flaws to persist in real-world implementations. There have been multiple devastating attacks on TLS from BEAST and CRIME to FREAK, POODLE, Logjam, RC4 NOMORE, and others, which happened only because servers and browsers continued to support legacy protocols and algorithms.

“Protocol implementations tend to support legacy ciphers until a concrete attack is demonstrated in a common usage of the protocol," said the INRIA researchers added in their paper."A series of recent attacks on TLS have conclusively shown that this line of defense for legacy ciphers is fatally flawed. Leaving old protocol versions and obsolete cryptographic algorithms enabled can lead to devastating attacks.Each attack is based on a classic cryptographic weakness that was known to cryptographers for years or even decades in advance, but had not been demonstrated in real-world TLS scenarios. So these works showed that with modern network speeds and computing power, the computational effort required to exploit the theoretical weakness is feasible even for academic researchers,” they added.

Although the 3DES cipher is used by only 1% of websites, is still supported by all the major browsers and 87% of the servers. Legacy protocols tend to be almost forgotten in software platforms, and nobody seems to want to take the chance of breaking anything by removing them.

However, the vendors of those software platforms (such as browser makers or server software developers) could still set a deadline for the deprecation of all the legacy protocols, even if that deadline is many years from now.

It would still be a better outcome than simply leaving the legacy protocols in software implementations until a new devastating attack appears, and then scrambling to mitigate against it. Furthermore, such swift actions would likely still end up breaking the services of those that rely on the legacy protocols, which makes the current inaction almost illogical. Better planning for protocol deprecation would go along way towards avoiding this kind of issues.

Mitigations Against SWEET32

The authors of the paper recommend three main ways to dealing with SWEET32 attack:

All web servers should be configured to prefer 128-bit (or higher) ciphers. 3DES should be offered by web browsers as fallback-only, even if the servers prefer 3DES over AES for encrypted connections.TLS libraries should limit the length of TLS sessions with a 64-bit cipher.

The INRIA researchers have contacted the main service and platform providers about their discovery, and they have all started to adopt counter-measures. The OpenVPN team will provide a warning to users who prefer 64-bit ciphers and will be encouraged to switch to AES-GCM. The OpenSSL software library will disable support for 3DES in its upcoming 1.1.0 release. Akamai will offer an option to customers to drop support for 3DES, and Apple has also disabled 3DES support on its icloud.com website. Mozilla will implement data limits for all ciphersuites soon, and Microsoft has removed 3DES from its False Start whitelist.