Sweet32 (CVE-2016-2183)

Sweet32 was published in 2016 by Karthikeyan Bhargavan and Gaëtan Leurent. Block ciphers with a 64-bit block, notably 3DES and Blowfish, start producing colliding ciphertext blocks in CBC mode after about 2^32 blocks, roughly 32 GB of data, by the birthday bound. A collision reveals the XOR of two plaintext blocks; if one is known and the other contains a repeated secret such as a cookie, the attacker can recover the secret. The researchers demonstrated it against HTTPS with 3DES and against OpenVPN with Blowfish by keeping a single connection open while generating large volumes of requests.

Why it matters

The attack needs an enormous amount of traffic over one connection, so it is not easy to carry out, but it showed that 64-bit block ciphers are unsuitable for modern data volumes. 3DES has since been phased out of browsers and TLS libraries' default configurations, and TLS 1.3 allows only AEAD ciphers with 128-bit blocks or stream constructions, such as AES-GCM and ChaCha20-Poly1305. The practical fix on servers is to remove every 3DES suite (for example TLS_RSA_WITH_3DES_EDE_CBC_SHA) from the cipher list.

Example

nmap --script ssl-enum-ciphers -p 443 example.com | grep -i 3des

No output means no 3DES suites are offered. An explicit nginx cipher list without them:

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

Common misconceptions

• 3DES is safe because its key is long. Sweet32 does not attack the key; it exploits the 64-bit block size, which key length does not change.
• Sweet32 decrypts any 3DES connection quickly. It needs tens of gigabytes or more on one connection; the lesson is to retire 64-bit ciphers, not that every short session is exposed.
• Removing 3DES breaks modern clients. Every current browser supports AES-GCM or ChaCha20-Poly1305; only very old clients depend on 3DES.