In short

Do not use 64-bit block ciphers such as 3DES, Blowfish or IDEA. With 64-bit blocks, collisions become likely after about 2^32 blocks (32 GiB) under one key, and in CBC a collision can reveal plaintext. NIST disallowed 3DES for encryption after 2023. Use AES-GCM or ChaCha20-Poly1305 with 128-bit blocks, and respect the usage limits of whatever construction you choose.

  • Block size, not key size, sets the birthday bound: 2^32 blocks of 8 bytes is 32 GiB.
  • In CBC, two equal ciphertext blocks reveal the XOR of their plaintext blocks.
  • A longer Blowfish or 3DES key does not change the 64-bit block size.
  • NIST disallowed 3DES (TDEA) for encryption after 31 December 2023; decryption of old data remains allowed.
  • Every AEAD has its own usage limits; count data per key rather than relying on a timeout.

Verify it

  1. Run testssl.sh --sweet32 host:443 against every TLS endpoint and confirm no 64-bit block cipher is offered.
  2. Offer only 3DES from a test client and confirm the handshake fails.
  3. Search configuration and code for DES-CBC3, 3DES, TDEA, BF-CBC and Blowfish.
  4. For any remaining legacy format, record the bytes encrypted per key and confirm rekeying happens far below 32 GiB.
Applies to

Why 64-bit block sizes constrain long-lived sessions. A collision estimate alone is not a complete attack.

Fix it in your stack

Tested fixes: the vulnerable code, the fix, a plausible fix that still fails, and the regression tests that tell them apart.

Learning goals and prerequisitesAbout 18 minutes: 4 to read and 14 for the exercise

What you will learn

  • Derive the birthday collision scale.
  • Use the CBC collision equation correctly.
  • Separate offered capability, exposure conditions, and recovery evidence.

Before you start

Engineers who still find 3DES or Blowfish in TLS, VPN or file formats, and reviewers who assess per-key data limits.

  • Understand block size, the birthday effect, and the difference between a collision and recovered plaintext.

Refresh first: ECB mode: why it leaks patterns and what to use instead

Go to the guided practice

Block size creates a separate limit from key size

A block cipher key selects a permutation, while the block size determines how many distinct block values exist. For 64-bit blocks there are 2⁶⁴ possible values. In a stream of roughly random block values, the expected number of colliding pairs after q blocks is approximately q(q−1)/(2×2⁶⁴). The collision probability is approximately 1−exp(−q(q−1)/(2×2⁶⁴)).

At q=2³² blocks, the expected pair count is about one half and the probability of at least one collision is about 39%. Each block is eight bytes, so that is 2³⁵ bytes: 32 GiB, or about 34.4 decimal GB. This is a scale at which collisions become likely, not a promise to recover a cookie at exactly that byte count.

In CBC, Cᵢ=Eₖ(Pᵢ XOR Cᵢ₋₁). If Cᵢ=Cⱼ under one key, the permutation has equal inputs: Pᵢ XOR Cᵢ₋₁=Pⱼ XOR Cⱼ₋₁. Rearranging gives Pᵢ XOR Pⱼ=Cᵢ₋₁ XOR Cⱼ₋₁. If one plaintext block is known, the other can be recovered from the preceding ciphertext blocks. A collision of arbitrary blocks may reveal only an unhelpful XOR.

A useful collision needs useful traffic structure

Sweet32 exploited long-lived traffic under one key, repeated secret material, and enough known or chosen plaintext; the case study at /domains/identity-crypto/encryption/sweet32/ covers the 2016 demonstrations. Different keys produce different permutations, so the simple equal-output implication cannot be carried across arbitrary key boundaries. Connections, sessions, and keys are not always one-to-one; the relevant quantity is blocks processed under each traffic key.

Increasing a 64-bit-block cipher’s key length does not change the birthday space. A 256-bit Blowfish key still encrypts 64-bit blocks. Conversely, the familiar birthday estimate is not a universal permission to encrypt up to a boundary with any mode: nonce limits, forgery bounds, message sizes, and protocol-specific constraints also matter. Modern AEAD usage limits must be taken from the actual construction; the AEAD record guide at /domains/identity-crypto/encryption/authenticated-record-design/ gives AES-GCM’s.

Replace the short-block construction; bound usage during transition

Move supported protocols to modern authenticated encryption. Enforced per-key data limits and rekeying can reduce collision opportunities during a constrained transition, but a connection timeout alone is a weak proxy: a fast connection can process substantial data before it expires. Count bytes or records where the protocol requires it and test that limits actually cause a fresh key.

A replacement affects both peers. Measure clients that cannot negotiate the intended suites, choose a migration deadline, and remove dormant fallback paths. Keep the distinction between key rotation and certificate renewal clear: changing a certificate does not necessarily rotate traffic keys in already established sessions.

The operational lesson is capacity planning for cryptography. Traffic volume, replication, retries, and parallel streams consume a per-key security budget. A cryptographic inventory should therefore include block size or AEAD usage limits and rekey behavior, rather than recording only an attractive key-length number.

What should you do today?

  • Remove 3DES, Blowfish, IDEA and RC2 from TLS, SSH and VPN configurations; Mozilla’s current TLS profiles contain none of them.
  • Check with testssl.sh --sweet32 host:443 for TLS, and review OpenVPN data-ciphers for BF-CBC or other 64-bit ciphers.
  • For stored data still encrypted with 3DES, decrypt and re-encrypt it with an AEAD; NIST still allows 3DES only for decrypting existing data.
  • Record block size and per-key usage limits in your cryptographic inventory, not just key length.

Check arithmetic, collision usefulness, and real key boundaries

The supplied one-byte CBC trace demonstrates the algebra with a deliberately tiny toy block. It does not simulate 64-bit security or require collecting gigabytes of traffic. In deployment tests, a valid replacement connection must work, a legacy-only offer must fail, and the largest allowed data volume must trigger the documented limit before it is exceeded.

Evidence that a service offers 3DES supports a configuration finding. Evidence that one connection transferred 32 GiB identifies a risky scale. Neither fact alone proves plaintext recovery. A recovery claim needs the repeated-secret structure, observed collision, key continuity, and calculation that connects the collision to a meaningful plaintext.

Guided practice

Use one-byte toy CBC blocks to reconstruct a secret block from a collision and compute the real 64-bit collision scale.

Supplied scenario material
Plain text
Supplied toy evidence under one key:
C_i = C_j = aa
Previous ciphertext bytes: C_(i−1)=35, C_(j−1)=a0
Known plaintext P_i=41 (hex, ASCII A)
CBC equation: P_i XOR P_j = C_(i−1) XOR C_(j−1).

  1. 1. Recover the unknown toy block

    Compute P_j using the three known bytes.

    Expected result and reasoning

    35 XOR a0=95; 41 XOR 95=d4. The recovered byte is d4. The equality must be under the same key.

  2. 2. Calculate the scale

    Convert 2^32 eight-byte blocks into GiB and estimate collision probability.

    Expected result and reasoning

    2^32×8=2^35 bytes=32 GiB. Expected pairs≈0.5 and probability≈1−e^(−0.5)≈39.3%.

  3. 3. Handle boundary evidence

    Decide whether a collision across two independently keyed connections or 32 GiB alone proves cookie recovery.

    Expected result and reasoning

    Neither proves it. Different keys invalidate the equal-input deduction; volume alone supplies no useful known-plaintext collision.

Your deliverable: The recovered toy byte, byte-volume calculation, and two reasons an exposure finding is not a demonstrated secret recovery.

The trace is supplied and uses an artificial block size. The exercise executes no real cipher and establishes no live-service exposure.

Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.

No draft saved on this device yet.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

  1. On the Practical (In-)Security of 64-bit Block Ciphers. ACM CCS 2016.
  2. NIST: Withdrawal of SP 800-67 Revision 2. 29 June 2023.
  3. RFC 9325: Recommendations for Secure Use of TLS and DTLS. November 2022 (BCP 195); updated by RFC 9852 and RFC 10015.
  4. NIST SP 800-131A Rev. 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths. Revision 2 (March 2019).

Reference information

ASVS 5.0.0 requirements
v5.0.0-11.3.2 · v5.0.0-12.1.2

Download this guide as Markdown