--- key: "crypto-sweet32-mechanism" title: "64-bit block ciphers and the Sweet32 mechanism" url: "https://softwaresecurity.com/domains/identity-crypto/encryption/64-bit-block-ciphers-sweet32/" api: "https://softwaresecurity.com/api/v1/articles/crypto-sweet32-mechanism.json" domain: "identity-crypto" topic: "Identity \u0026 cryptography" type: "Reference" identifiers: ["CWE-327","CWE-326","A04:2025","V11.3.2","V12.1.2"] tags: ["Encryption","Historical cryptographic attacks"] stages: ["design","build"] roles: ["developer"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # 64-bit block ciphers and the Sweet32 mechanism Calculate the birthday effect for 64-bit blocks and derive the CBC relation that can turn a collision into a plaintext disclosure. Canonical URL: https://softwaresecurity.com/domains/identity-crypto/encryption/64-bit-block-ciphers-sweet32/ ## 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. ## What you will learn - Derive the birthday collision scale. - Use the CBC collision equation correctly. - Separate offered capability, exposure conditions, and recovery evidence. Audience: Engineers who still find 3DES or Blowfish in TLS, VPN or file formats, and reviewers who assess per-key data limits. Before you start: - Understand block size, the birthday effect, and the difference between a collision and recovered plaintext. Time: About 18 minutes: 4 to read and 14 for the exercise ## 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 material ```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. Recover the unknown toy block Compute P_j using the three known bytes. Worked answer: 35 XOR a0=95; 41 XOR 95=d4. The recovered byte is d4. The equality must be under the same key. ### 2. Calculate the scale Convert 2^32 eight-byte blocks into GiB and estimate collision probability. Worked answer: 2^32×8=2^35 bytes=32 GiB. Expected pairs≈0.5 and probability≈1−e^(−0.5)≈39.3%. ### 3. Handle boundary evidence Decide whether a collision across two independently keyed connections or 32 GiB alone proves cookie recovery. Worked answer: Neither proves it. Different keys invalidate the equal-input deduction; volume alone supplies no useful known-plaintext collision. Deliverable: The recovered toy byte, byte-volume calculation, and two reasons an exposure finding is not a demonstrated secret recovery. Scope: The trace is supplied and uses an artificial block size. The exercise executes no real cipher and establishes no live-service exposure. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [On the Practical (In-)Security of 64-bit Block Ciphers](https://sweet32.info/SWEET32_CCS16.pdf). ACM CCS 2016. - [NIST: Withdrawal of SP 800-67 Revision 2](https://csrc.nist.gov/news/2023/nist-to-withdraw-sp-800-67-rev-2). 29 June 2023. - [RFC 9325: Recommendations for Secure Use of TLS and DTLS](https://www.rfc-editor.org/rfc/rfc9325.html). November 2022 (BCP 195); updated by RFC 9852 and RFC 10015. - [NIST SP 800-131A Rev. 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths](https://csrc.nist.gov/pubs/sp/800/131/a/r2/final). Revision 2 (March 2019).