← All modules
Symmetric-key·18 min

The Data Encryption Standard (DES)

AES's predecessor and the first cipher the world ever standardized. What retired it wasn't a flaw in the design — it was a key that was always too short.

Developer / EngineerSecurity ArchitectResearcher / Academic

Why DES came first

DES was developed by IBM in the early 1970s (building on an earlier IBM cipher called Lucifer) in consultation with the NSA, and adopted as a U.S. government standard in 1977 — the direct ancestor of the 1970s revolution covered in the history module, and the first symmetric cipher to be publicly standardized, openly published, and thoroughly analyzed by the wider cryptographic community, rather than kept secret by whoever designed it.

It protected banking, government, and commercial traffic for nearly three decades before being formally withdrawn in 2005 — far longer than its designers expected. What eventually retired it wasn't a mathematical flaw in the cipher's structure; it was a key that was always too short, a lesson directly connected to the key-size guidance covered elsewhere in this catalog.

The Feistel network: DES's core structure

DES processes each 64-bit block by splitting it into two 32-bit halves and running them through 16 rounds of a Feistel network: each round takes the right half, transforms it with a round function F (keyed by that round's subkey), XORs the result into the left half, then swaps the two halves for the next round. This structure has one elegant, load-bearing property: decryption uses the exact same network, just with the round keys applied in reverse order — no separate "inverse" algorithm is needed, regardless of how complicated F itself is.

That property is a genuine trade-off against AES's design (covered in the previous module): AES's substitution-permutation network needs a distinct, deliberately designed inverse for every step (InvSubBytes, InvShiftRows, InvMixColumns), while a Feistel network gets decryption essentially for free, at the cost of only transforming half the block each round instead of all of it.

One Feistel round

  1. 1

    Split

    The 64-bit block (after an initial fixed bit permutation) splits into a 32-bit left half L and right half R.

  2. 2

    Transform

    The round function F combines R with this round's 48-bit subkey (derived from the main key), producing a 32-bit output.

  3. 3

    Mix

    F's output is XORed into L, producing the new right half for the next round.

  4. 4

    Swap

    The old R becomes the new L, and the mixed result becomes the new R — repeated for 16 rounds total.

DES's numbers, and why 56 bits stopped being enough

DES encrypts a 64-bit block using a key stored as 64 bits but only 56 bits of which are actually used for security — the remaining 8 bits are parity-check bits, one per byte, left over from an earlier era of unreliable hardware. That 56-bit effective key size was already a point of public controversy when DES was standardized in 1977, and it's the entire reason DES was eventually retired: computing power grew until exhaustive key search — trying every one of the 2⁵⁶ possible keys — became achievable.

That milestone arrived concretely in January 1999, when the EFF's purpose-built "Deep Crack" machine, combined with the distributed.net volunteer computing project, found a DES key by brute force in 22 hours and 15 minutes — a well-documented, widely cited demonstration that DES's key size, not its internal design, had become the weak point.

expected keys to try≈2562=255(brute force finds the key after searching, on average, half the keyspace)\text{expected keys to try} \approx \frac{2^{56}}{2} = 2^{55} \quad \text{(brute force finds the key after searching, on average, half the keyspace)}

Practice

A brute-force machine tests keys at roughly 2⁴⁰ (about 1.1 trillion) keys per second. On average, brute force finds the correct DES key after searching half the 2⁵⁶ keyspace — that's 2⁵⁵ keys. How many seconds would that take?

Go deeper3DES and the meet-in-the-middle problem⌄

The obvious fix for a too-short key is running DES multiple times with different keys — but the naive version of that idea, double DES (encrypt with key K1, then again with key K2), turns out to add almost no real security over single DES. A meet-in-the-middle attack defeats it: for a known plaintext/ciphertext pair, an attacker precomputes and stores the encryption of the plaintext under every one of the 2⁵⁶ possible K1 values in a lookup table, then tries decrypting the ciphertext under every possible K2 value, checking each result against that table. A match reveals both keys — in roughly 2⁵⁶ + 2⁵⁶ ≈ 2⁵⁷ total operations, not the 2¹¹² a naive "two independent 56-bit keys" estimate would suggest, at the cost of needing to store that 2⁵⁶-entry table in memory.

This is exactly why real-world triple DES (3DES) uses three passes in an encrypt-decrypt-encrypt pattern (with either two or three distinct keys) rather than stopping at two — the extra pass specifically closes the meet-in-the-middle gap, at the cost of running the DES round structure three times over for every block. Even so, 3DES's 64-bit block size (shared with single DES) has its own separate weakness at scale, which is why AES, with a 128-bit block and no such attack, fully replaced it rather than the industry settling on 3DES long-term.

double-DES, naive estimate: 2112double-DES, meet-in-the-middle: ≈257\text{double-DES, naive estimate: } 2^{112} \qquad \text{double-DES, meet-in-the-middle: } \approx 2^{57}

Practice

Naive intuition suggests double-DES (two independent 56-bit keys) gives 2¹¹² security. Meet-in-the-middle cuts that down to about 2⁵⁷. Expressed as an exponent of 2, how many times weaker is that (112 − 57)?

DES's legacy: what AES kept, and what it dropped

AES deliberately abandoned the Feistel structure in favor of a substitution-permutation network (covered in the previous module) — a design that transforms the entire block every round instead of just half of it, converging to full diffusion in fewer rounds. What DES's era did establish and AES kept: a public, competitive standardization process (DES's NSA involvement, though it turned out not to have weakened the cipher, drove exactly the kind of public distrust that made AES's fully open NIST competition the model going forward), S-box-based non-linearity, and a fixed, published, thoroughly scrutinized algorithm rather than a proprietary secret one.

Knowledge check

Test what you just learned →

10 quick questions, with an explanation for every answer.

Up next

Stream ciphers & ChaCha20-Poly1305 →

Not every symmetric cipher works in fixed blocks. ChaCha20 generates a keystream instead — and paired with Poly1305, it's AES-GCM's fastest rival.