Cybersecurity glossary
What is SWEET32 (CVE-2016-2183)?
Learn what SWEET32 (CVE-2016-2183) is, how 64-bit TLS ciphers like 3DES hit birthday collision bounds, which long-lived HTTPS sessions were at risk, and how to disable legacy 64-bit suites.
Definition
SWEET32, associated with CVE-2016-2183 (and related findings), is a practical birthday-bound attack against 64-bit block ciphers such as 3DES and Blowfish in TLS and other protocols: after enough data is encrypted under one session key, colliding ciphertext blocks can leak plaintext information about HTTPS cookies and similar secrets.
Why SWEET32 mattered
Security teams spent years hunting protocol bugs and implementation oracles. SWEET32 reminded everyone of a quieter limit: block size. With a 64-bit block cipher, the birthday bound arrives after roughly 2^32 blocks—large, but no longer science fiction for long-lived HTTPS connections that keep encrypting under one key.
Assigned discussions around CVE-2016-2183 put 3DES TLS suites back on the chopping block. Even when 3DES encryption was still “correct,” using it at Internet scale for hours of traffic crossed a cryptographic safety line.
What SWEET32 actually is
SWEET32 is a birthday-bound collision attack on protocols that encrypt large volumes of data with 64-bit block ciphers in CBC mode (notably Triple DES in TLS). When two ciphertext blocks collide, CBC relationships can reveal XOR differences of underlying plaintexts. With attacker-influenced plaintext and known HTTP structure, those leaks can recover cookie bytes.
Vulnerable ciphers
64-bit block algorithms such as 3DES (and Blowfish in some non-TLS contexts).
Dangerous condition
Very large data volume under one session key without timely rekeying.
Leak mechanism
Ciphertext block collisions expose plaintext XOR relationships useful for secret recovery.
Web impact
HTTPS session cookies and similarly structured secrets in long connections.
How the SWEET32 attack works
Negotiate a 64-bit suite
Client and server agree on a TLS cipher suite using 3DES or another 64-bit block cipher.
Keep the session alive
A long-lived HTTPS connection continues encrypting many responses under the same keys.
Generate attacker-influenced traffic
Malicious content causes repeated requests so known and secret plaintext share the encrypted stream.
Collect colliding blocks
After sufficient volume, identical ciphertext blocks appear with non-negligible probability.
Infer plaintext relationships
CBC collision math yields XOR differences that help recover secret cookie material.
The attack is not “break 3DES with a laptop in seconds.” It is “do not encrypt tens of gigabytes with a 64-bit block cipher under one key on the public web.”
SWEET32 compared with related limits
| Property | SWEET32 | Generic birthday | BEAST |
|---|---|---|---|
| Core math | Block collision at ~2^(b/2) | Hash/output collision bound | Predictable CBC IV misuse |
| b for classic demo | 64-bit cipher blocks | n-bit hash digests | TLS 1.0 CBC records |
| Needs obsolete TLS version? | No—volume + 3DES enough | N/A | TLS 1.0 CBC specific |
| Primary fix | Disable 64-bit suites | Longer digests | Modern TLS + IV fixes |
| AES-GCM affected? | Not the 64-bit SWEET32 case | Different bounds apply | No (not CBC IV issue) |
Who was affected
Sites that still offered 3DES—often as a last-resort compatibility suite—were in scope when browsers could be steered into that suite and connections remained open long enough. Corporate gateways that preferred 3DES for legacy policy reasons were particularly exposed.
VPN and application protocols using Blowfish or other 64-bit ciphers faced the same birthday-bound logic even when CVE branding focused on TLS 3DES.
Mitigations
Disable 3DES in TLS
Remove 3DES cipher suites from servers, CDNs, and appliances so clients cannot negotiate them.
Prefer 128-bit block AEAD
Use AES-GCM or ChaCha20-Poly1305 with modern TLS versions as the default path.
Rekey if stuck on legacy
If a 64-bit cipher must remain temporarily, enforce short rekey limits far below birthday bounds.
Monitor negotiations
Alert when any client still selects 3DES—treat it as both a crypto and inventory signal.
What practitioners should do today
- Scan public and internal TLS terminators for 3DES and other 64-bit block cipher suites.
- Disable those suites in Mozilla Intermediate/Modern compatible configurations.
- Verify CDNs, API gateways, and mail TLS listeners—not only the primary website.
- Upgrade or replace appliances that cannot turn off 3DES.
- Review VPN and app crypto configs for Blowfish or 3DES at high data volumes.
- Prefer TLS 1.2+ with AEAD; enable TLS 1.3 where possible.
- Track NIST and industry deprecation timelines for Triple DES in all roles.
- Document rare compatibility exceptions with hard removal dates.
Lessons SWEET32 left for cryptography ops
SWEET32 made birthday bounds an operations metric: gigabytes per key, hours per session, cipher block size. Cryptographic agility is not only about algorithm names—it is about whether your traffic volumes still fit the math you silently assumed in 1999.
It also showed that “backup cipher suites” kept for emergencies become the emergency. If 3DES is negotiable, someone will eventually negotiate it.
The practical takeaway
SWEET32 (CVE-2016-2183) exploits birthday collisions in 64-bit block ciphers such as 3DES when TLS sessions encrypt too much data under one key. Disable those suites, move to AES-GCM or ChaCha20-Poly1305, and treat any remaining 64-bit cipher as a time-boxed exception—not a permanent compatibility feature.
Related security terms
Birthday Attack
The combinatorial collision principle SWEET32 applies to 64-bit cipher blocks at high volume.
Cipher Suite
TLS negotiation surface where 3DES and other 64-bit CBC suites must be disabled.
SSL/TLS
Protocols that historically allowed long-lived sessions using 64-bit block ciphers.
HTTPS
Web traffic where SWEET32 demonstrated cookie plaintext leakage risks.
Advanced Encryption Standard (AES)
128-bit block cipher that raises the birthday bound far beyond SWEET32’s practical regime.
Frequently asked questions
What is SWEET32 in simple terms?
SWEET32 shows that old 64-bit ciphers like 3DES become unsafe when a TLS connection encrypts a huge amount of data with one key. Block collisions eventually leak information about secrets such as cookies.
What is CVE-2016-2183?
CVE-2016-2183 is commonly cited for the SWEET32 birthday-bound issues affecting 64-bit block ciphers in TLS and related contexts, especially 3DES.
How much data is ‘enough’ for SWEET32?
On the order of tens of gigabytes encrypted under the same key in a long-lived connection—large but achievable against busy HTTPS sessions that never rekey and still use 3DES.
Does AES-128 suffer the same practical attack?
AES uses 128-bit blocks, so the birthday bound is vastly higher. SWEET32’s practical web demos targeted 64-bit ciphers, not AES.
Is 3DES still needed for compatibility?
Almost never for modern browsers. Keeping 3DES enabled for ancient clients recreates SWEET32 risk and should be retired with a migration plan.
How do you mitigate SWEET32?
Disable 3DES and other 64-bit block cipher suites in TLS, prefer AES-GCM or ChaCha20-Poly1305, and ensure sessions rekey well before birthday bounds if a legacy cipher cannot yet be removed.
Was OpenVPN or Blowfish also discussed?
Yes. Researchers also highlighted Blowfish’s 64-bit blocks in some VPN configurations, reinforcing that the issue is block size under one key, not a single TLS brand name.
References
Explore authoritative guidance and frameworks related to sweet32 (cve-2016-2183).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.