The sweet32 attack is what happens when a cipher with a small block size runs for too long under one key. Ciphers like 3DES and Blowfish use a 64 bit block, and once you encrypt enough traffic, two ciphertext blocks are bound to collide by pure probability. In CBC mode a collision leaks the XOR of two plaintext blocks, and if one of them is a secret that repeats in every request, the attacker reads it out. This post explains the birthday bound that makes it inevitable and why the fix is to retire 64 bit block ciphers.
The birthday bound in one paragraph
The birthday problem says that in a group of 23 people, two probably share a birthday, far sooner than intuition expects. The same math applies to block cipher outputs. For a block size of n bits, you expect a collision among random looking ciphertext blocks after roughly 2^(n/2) of them, not 2^n. That square root is the whole story. For a 64 bit block, the bound is about 2^32 blocks. For a 128 bit block like AES, it is about 2^64, which no real connection reaches.
64 bit block -> collision near 2^32 blocks (reachable) 128 bit block -> collision near 2^64 blocks (not reachable)
Two to the 32 blocks of 8 bytes each is around 32 gigabytes of traffic under a single key. A long running connection that moves that much data is ordinary, and that is the window the attack needs.
Why the sweet32 attack leaks plaintext
Collisions alone would just be a curiosity. CBC mode turns them into plaintext recovery. Recall how CBC builds each ciphertext block:
C[i] = E(key, P[i] XOR C[i-1])
The block cipher is a permutation, so equal outputs mean equal inputs. If two ciphertext blocks collide, C[i] = C[j], then their inputs matched too:
P[i] XOR C[i-1] = P[j] XOR C[j-1]
Rearrange it and the attacker, who can see all the ciphertext, learns something about the plaintext:
P[i] XOR P[j] = C[i-1] XOR C[j-1] (both known)
The right side is two ciphertext blocks the attacker already captured, so the XOR of two plaintext blocks drops out for free. Now the trap closes. If one of those plaintext blocks is a fixed secret that the client sends in every single request, say an auth token or a session cookie, then it is the same value in countless positions. The attacker waits for that secret block to collide with a block they know, and the XOR hands them the secret directly.
A small block size is not a flaw in the cipher’s math. It is a fuel gauge. Burn enough data under one key and a collision is not a risk, it is a schedule.
Picture a VPN or an HTTPS session for a SaaS app called Acme Notes that negotiated a 64 bit block cipher and keeps the connection open for hours. A browser replays the same session cookie on every request inside that tunnel. An attacker who can nudge the client into generating a lot of traffic, and who watches the encrypted stream, collects blocks until the cookie block collides with a known block. The cookie falls out, and no part of the cipher was actually broken.
How a connection ends up here
The weakness is a configuration choice that outlived its safety margin.
- Legacy cipher suites left enabled. A server keeps 3DES in its TLS configuration for compatibility with very old clients, and a downgrade lands a modern client on it.
- Long running tunnels on one key. A VPN or a database link that stays up for hours and never rekeys gives the attacker the volume they need.
- A repeated secret in the stream. Any value that appears in the same place in every message, like a cookie or a fixed header, is the ideal target block.
Getting a victim onto the weak cipher in the first place often rides on a cipher downgrade attack, which nudges a handshake down to the worst option both sides will accept. The underlying idea, that a repeated or colliding value leaks the XOR of two plaintexts, is the same one behind a keystream reuse attack. You can read more foundations under vulnerability basics, and the full set sits in our cryptographic oracle attacks hub.
How to fix it
The fix is to stop feeding the fuel gauge.
- Retire 64 bit block ciphers. Disable 3DES, Blowfish, and other 64 bit block ciphers in TLS, VPN, and application configs. Prefer AES, which has a 128 bit block and pushes the birthday bound out of reach.
- Prefer an authenticated 128 bit mode. AES GCM or ChaCha20 Poly1305 give a large effective state and add integrity, so you are not leaning on block size alone.
- Rekey long connections. If you cannot move off a 64 bit cipher yet, cap the data per key far below the birthday bound and rekey well before you approach 32 gigabytes on one key.
- Shorten session lifetimes. Tear down and renegotiate long tunnels so no single key ever sees enough traffic to collide.
- Remove repeated secrets from the stream where you can. The attack needs a constant target block, so anything that reduces a fixed secret repeating in place lowers the payoff.
The shape is the same as the other entries in this cluster. The cipher is doing its job. The failure is an assumption, that one key can encrypt unlimited data, which a 64 bit block quietly makes false after a few tens of gigabytes. The config line that enables the old cipher looks harmless on its own.
Spotting this means reasoning about how an application builds and protects a long encrypted stream, which cipher it settled on, and how much data runs under a single key before anything rotates. That is the kind of assumption an autonomous researcher is built to test. Read more on our about page.
Frequently asked questions
What is the Sweet32 attack?
It is a birthday bound attack on ciphers with a 64 bit block, such as 3DES and Blowfish, used in CBC mode over a long connection. After about two to the 32 blocks under one key, two ciphertext blocks are likely to collide. In CBC a collision reveals the XOR of two plaintext blocks, and if one is a secret that repeats in every request, the attacker recovers it without breaking the cipher.
Why does a 64 bit block size make this possible?
The birthday bound says collisions appear after roughly two to the power of half the block size, not the full size. For a 64 bit block that is about two to the 32 blocks, which at 8 bytes each is near 32 gigabytes of traffic under one key, a volume a long running tunnel reaches. A 128 bit block like AES pushes the bound to two to the 64, which no real connection gets near.
How does a collision leak plaintext in CBC?
The block cipher is a permutation, so equal ciphertext blocks mean equal inputs. If two ciphertext blocks are equal, then each plaintext block XORed with its preceding ciphertext block must also be equal. Rearrange that and the XOR of the two plaintext blocks equals the XOR of the two preceding ciphertext blocks, which are values the attacker already captured. So the XOR of two plaintext blocks falls out for free. When one block is a known value and the other is a repeated secret, the secret is recovered.
How do you prevent the Sweet32 attack?
Retire 64 bit block ciphers. Disable 3DES and Blowfish in TLS, VPN, and application configs and prefer AES, which has a 128 bit block. Use an authenticated mode like AES GCM or ChaCha20 Poly1305. If you must keep a 64 bit cipher for now, rekey long connections and cap the data per key far below the birthday bound, and shorten session lifetimes so no key sees enough traffic to collide.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.