In short

Sweet32 (2016) showed that 64-bit block ciphers such as 3DES and Blowfish leak secrets in practice: the researchers recovered an HTTPS cookie from about 610 GB of traffic captured over 30.5 hours on long-lived connections. Today, disable 3DES and Blowfish in TLS, SSH and VPNs, use AES-GCM or ChaCha20-Poly1305, and limit data per key by counting bytes rather than trusting connection timeouts.

  • The attack needed one key, a lot of traffic and a secret repeated in that traffic.
  • Long-lived keep-alive connections let one 3DES key protect hundreds of gigabytes.
  • OpenSSL 1.1.0 removed 3DES from its default cipher list in response.
  • NIST disallowed 3DES for encryption after 31 December 2023.
  • Keep three findings apart: support for a weak cipher, traffic exposure, and demonstrated recovery.

Incident at a glance

Date
Category
Cryptographic weakness
Organizations
  • OpenSSL Project
  • OpenVPN
  • Microsoft (IIS)
Impact
Long-lived connections encrypted with 64-bit block ciphers, 3DES in TLS and Blowfish in OpenVPN, leaked repeated secrets through birthday collisions. The researchers recovered an HTTPS cookie from 610 GB of traffic captured in 30.5 hours.
How it was found
Karthikeyan Bhargavan and Gaëtan Leurent of INRIA demonstrated the attacks and coordinated disclosure with OpenSSL, OpenVPN and browser vendors.

Timeline

  1. Sweet32 is disclosed; OpenSSL announces it is moving 3DES out of its HIGH cipher group.
  2. OpenSSL 1.1.0 is released with 3DES suites disabled by default.
  3. OpenSSL 1.0.2i and 1.0.1u move 3DES suites to MEDIUM (CVE-2016-2183).
  4. The paper is presented at ACM CCS 2016.
  5. NIST announces that 3DES encryption is disallowed after 31 December 2023 and that SP 800-67 Rev. 2 will be withdrawn.
  6. NIST withdraws SP 800-67 Rev. 2; 3DES remains allowed only for decrypting existing data.

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 DES-CBC3-SHA from a test client and confirm the handshake fails.
  3. Review VPN configurations for BF-CBC, DES or 3DES and confirm the negotiated cipher on a live tunnel.
  4. For any remaining legacy link, record bytes per key and confirm rekeying far below 32 GiB.
Applies to

Historical Sweet32 conditions in long sessions. It is not a general claim that every block collision reveals a secret.

Part of
Collection: case studies

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 17 minutes: 4 to read and 13 for the exercise

What you will learn

  • Separate mathematical bounds from demonstrated attack costs.
  • Account for bytes per traffic key.
  • Use historical measurements without presenting them as current facts.

Before you start

Engineers who operate TLS and VPN endpoints, and reviewers who need to judge a 3DES or Blowfish finding.

  • Calculate a birthday-bound block count and identify what repeated attacker-influenced traffic supplies.

Refresh first: 64-bit block ciphers and the Sweet32 mechanism

Go to the guided practice

A long session made an old bound operationally relevant

The 2016 Sweet32 work by Bhargavan and Leurent demonstrated practical consequences of birthday collisions in 64-bit block ciphers. The underlying collision bound was established cryptographic knowledge; the contribution was showing useful secret recovery in real protocol settings, including TLS with 3DES and OpenVPN with Blowfish.

For CBC under one key, equal ciphertext blocks imply an XOR relation between the corresponding plaintext blocks and their preceding ciphertext blocks. A collision between an unknown secret block and a known block can therefore reveal the secret block. A long connection with repeated cookies and controllable or predictable request material creates opportunities for a useful collision.

The rough birthday scale for 64-bit blocks is 2³² blocks, or 32 GiB; the mechanism page at /domains/identity-crypto/encryption/64-bit-block-ciphers-sweet32/ derives it. That is not the data volume of every full secret-recovery attack. The researchers’ described HTTPS experiment recovered a two-block cookie from a 610 GB trace over 30.5 hours in their particular setup. Their estimates and experiments depend on alignment, traffic structure, and connection behavior.

The application supplied repetition and the server supplied longevity

A browser repeatedly includes a cookie when sending requests to its origin. If an attacker can induce many requests while observing encrypted traffic, the same secret is encrypted amid many known fields. A server that permits very long connections may retain one traffic key long enough to accumulate the collision opportunities.

The researchers tested particular browsers and servers and measured particular deployment populations in 2016. Those percentages are historical measurements, not a current estimate of the Internet. Likewise, a proof of concept on an old IIS configuration does not imply every service offering 3DES allows the same volume under one key.

Data spread over independently keyed sessions does not create the same collision pool as one continuous key. The full research considers broader session patterns, but the simple explanation must track the correct key boundary. Counting aggregate bytes across an entire fleet can exaggerate or hide the per-key risk.

Treat cryptographic lifetime as a measurable quantity

Replace obsolete 64-bit-block suites and supported VPN configurations with maintained modern profiles. During a limited transition, enforce appropriate data or record limits and genuine rekeying. A wall-clock timeout without traffic accounting is weak at high throughput, and restarting an application request does not necessarily create a new TLS traffic key.

Increasing the symmetric key length does not increase the block size. Certificate renewal is also unrelated to the collision space of existing encrypted sessions. The controls must target the construction and its usage volume, not whichever key-related setting is easiest to change.

Removing a legacy suite can affect old devices. Measure those dependencies and migrate or isolate them with a deadline. A service-wide compatibility exception that permits every client to negotiate the weak suite broadens the exposure beyond the small group that supposedly needs it.

What should you do today?

  • Remove 3DES (DES-CBC3) and other 64-bit block ciphers from every TLS endpoint and client, and check with testssl.sh --sweet32 host:443.
  • In OpenVPN, set data-ciphers to AES-GCM or ChaCha20-Poly1305 and remove BF-CBC from any compatibility setting.
  • Where a legacy peer cannot be upgraded yet, isolate it and enforce a byte limit per key with real rekeying.
  • Re-encrypt stored 3DES data with an AEAD, as in the AEAD record guide at /domains/identity-crypto/encryption/authenticated-record-design/; NIST allows 3DES only to decrypt existing data.

Convert traffic measurements into bounded conclusions

An accepted 3DES handshake establishes support. A per-key volume record establishes traffic exposure. A useful CBC collision plus known-plaintext reasoning supports a recovery claim. Keep those three levels separate in findings and remediation reports.

After migration, show the intended client succeeds, a legacy-only offer fails, and sustained traffic follows the replacement’s documented key-update or usage-limit behavior. Do not carry the 32 GiB figure into an unrelated AEAD design as a universal safe limit; consult that algorithm and protocol’s requirements.

Guided practice

A service owner presents aggregate byte counts as proof of Sweet32 exposure. Reconstruct the key-level picture.

Supplied scenario material
Plain text
Session S1: key K1, 8 GiB; S2: key K1, 24 GiB.
Session S3: key K2, 20 GiB; S4: key K3, 20 GiB.
All four use a hypothetical 64-bit CBC construction.
A separate report says “two-block cookie recovered at 610 GB in 30.5 hours in the published experiment.”

  1. 1. Count per key

    Add the bytes processed under each key and convert K1’s volume into blocks.

    Expected result and reasoning

    K1 processes 32 GiB = 2^35 bytes = 2^32 eight-byte blocks. K2 and K3 each process 20 GiB; their counts are not one combined collision pool.

  2. 2. Interpret the boundary

    State whether K1’s volume alone proves a cookie was recovered.

    Expected result and reasoning

    No. It reaches a scale with appreciable collision probability, but the fixture supplies no collision or known-secret relation.

  3. 3. Interpret historical evidence

    Decide whether the published 610 GB result is a universal attack requirement or a current deployment measurement.

    Expected result and reasoning

    Neither. It describes one demonstrated setup. It supports practical feasibility under stated conditions, not an invariant threshold or today’s server population.

Your deliverable: A per-key usage table and three claims labeled support, exposure, or demonstrated recovery.

All service counts are supplied examples. No traffic is generated and the historical experiment is not reproduced.

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. Bhargavan and Leurent: Sweet32 research and demonstrations
  2. OpenSSL: The SWEET32 issue, CVE-2016-2183 (August 2016)
  3. NIST: withdrawal of SP 800-67 Rev. 2 and the end of TDEA encryption (2023). 29 June 2023.
  4. RFC 9325: Recommendations for Secure Use of TLS and DTLS. November 2022 (BCP 195); updated by RFC 9852 and RFC 10015.
  5. OpenSSL Security Advisory: SWEET32 mitigation in 1.0.2i and 1.0.1u. 22 September 2016.

Reference information

ASVS 5.0.0 requirements
v5.0.0-12.1.2

Download this guide as Markdown