Until the 1970s, strong cryptography was the domain of governments. The customers for cipher machines were armies and foreign ministries. The designs were secret, and the people who evaluated them worked for intelligence agencies. Then banks began installing automated teller machines and moving money over telephone lines, and companies began archiving data and sharing computers across networks. A commercial market for encryption appeared, and its customers had no way to tell a good cipher from a bad one.

The response was a public standard, and the process of creating it turned cryptography into an academic discipline. This part covers the two resulting ciphers, DES and AES, along with the stream cipher ChaCha20, which is now used alongside AES on the Internet. It also covers the modes of operation that make a block cipher usable on real data and the ways modern ciphers are attacked. Every design in this part is built to provide Shannon’s confusion and diffusion.

Block Ciphers

A block cipher encrypts a fixed-size block of bits, typically 64 or 128, into a block of the same size. For a given key, the cipher is a one-to-one mapping of all possible blocks, a permutation in the mathematical sense: every input block maps to exactly one output block, and every output block comes from exactly one input. If you change the key, the cipher becomes a different permutation. A 128-bit block has \(2^{128}\) possible values, and a good cipher with a random key should look, to anyone without the key, like a permutation of those values chosen at random.

A random permutation of \(2^{128}\) elements cannot be stored (there’s not enough storage on Earth for a table that size). Instead, block ciphers approximate one through repetition:

• The input block is loaded into a small array of bytes called the state.

• A round applies a fixed sequence of basic operations to the state, and the cipher runs the round many times.

• A key schedule permutes and expands the secret key into a separate round key for each round, so that every round mixes in fresh key material and each round is a function of a different round key.

After enough rounds, the relationship between input, output, and key has been scrambled to the point where no known analysis can recover it. This is the alternation of substitution and mixing that Shannon proposed, and the two designs below are the two standard ways to implement it.

Substitution-Permutation Networks

A substitution-permutation network (SPN) is the most direct realization of confusion and diffusion. Each round has three steps:

1. Substitution. Each byte of the state is replaced by looking it up in an S-box, a fixed 256-entry table chosen so that the mapping is nonlinear. This is the confusion step.

2. Permutation. The bytes are moved to new positions and mixed with their neighbors, so that a change in one byte spreads to several. This is the diffusion step.

3. Key addition. The round key is XORed into the state.

Decryption runs the same steps in reverse, using inverse tables and the round keys in reverse order. The S-box and the mixing must both be invertible, which constrains the design. AES, the Advanced Encryption Standard, is an SPN.

Feistel Networks

A Feistel network, named for Horst Feistel, the IBM cryptographer who developed it in the early 1970s, removes that constraint. It builds an invertible cipher out of a round function that does not have to be invertible.

The block is split into a left half \(L\) and a right half \(R\). Each round:

1. Computes a function \(F\) of the right half and the round key

2. XORs the result into the left half

3. Swaps the halves:

\[L_{i+1} = R_i, \qquad R_{i+1} = L_i \oplus F(R_i, K_i)\]

The function \(F\) can be any operation that mixes bits well and runs fast, such as table lookups, bit shuffles, or additions. It never has to be inverted.

To decrypt, the receiver has \(R_i\), which was passed through unchanged as \(L_{i+1}\), so it can recompute \(F(R_i, K_i)\) and XOR it back out of \(R_{i+1}\) to recover \(L_i\). Decryption is the same sequence of rounds as encryption, with the round keys in reverse order. The halves are not swapped after the final round in either direction, which is what makes the two directions line up. The same hardware or code serves both directions. DES is a Feistel cipher, and so are many of its contemporaries.

DES

In 1973, the U.S. National Bureau of Standards (now the National Institute of Standards and Technology, NIST) issued a request for proposals for a cipher to be standardized for use by government agencies and industry. None of the submissions was usable. A second request in 1974 brought a submission from IBM, based on a cipher called Lucifer that Feistel’s group had designed for a banking product. The National Security Agency (NSA) reviewed the design and negotiated changes, and the result was published as the Data Encryption Standard (DES) in January 1977.

DES is a Feistel cipher with a 64-bit block, a 56-bit key, and 16 rounds. (The key is written as 64 bits, but eight of them are parity bits for catching errors when the key is entered, and they add nothing to the security.)

Each round’s \(F\) function expands the 32-bit right half to 48 bits by duplicating some of them and XORs in a 48-bit round key. It then passes the result through eight S-boxes, each of which turns 6 input bits into 4 output bits, and permutes the 32 resulting bits. The S-boxes are the only nonlinear step, and so the only source of confusion, which is why the controversy described next centered on them. The permutations were chosen to be cheap in hardware, since the goal was a chip that could encrypt at line speed, and DES in software was always slower than its successors.

DES was designed for hardware implementation because even high-end mainframe computers of that era executed code at around 3 million instructions per second, roughly 30,000 to 60,000 times slower than a current Intel Core i9. Encrypting and decrypting would consume too much of the processor’s resources.

The DES Controversy

DES was the first cipher to be debated publicly, and two of the changes the NSA had negotiated drew most of the criticism. Lucifer had a 128-bit key. The standard had 56 bits, and critics said that it was chosen so that the government could break it. And the S-boxes, the one nonlinear component and therefore the one that determined the cipher’s resistance to analysis, had been redesigned without explanation. Nobody outside IBM and the NSA knew what the design criteria were.

In 1990, two Israeli researchers, Eli Biham and Adi Shamir, published a technique called differential cryptanalysis, described below. It broke many ciphers of the DES generation outright, and against DES itself, it gained almost nothing. The DES S-boxes turned out to be almost optimal against an attack that did not exist when they were designed, and nobody at IBM or the NSA could explain why.

In 1994, seventeen years after the standard, Don Coppersmith of IBM published the original design criteria and explained why they had been kept secret. IBM had discovered differential cryptanalysis in 1974 and built DES to resist it. It then agreed with the NSA to say nothing, since publishing the attack would have weakened every other cipher in use. The S-boxes had been strengthened, not weakened as people suspected. However, the key length was the actual weakness.

Key Length and Block Size

A 56-bit key has \(2^{56}\), or about \(7.2 \times 10^{16}\), possible values. In 1977, Whitfield Diffie and Martin Hellman, two Stanford researchers (we’ll see their names again), estimated that a machine costing $20 million could try all of them in a day. They predicted that within a decade, the cost would be within reach of a well-funded organization. The NBS disagreed, but Diffie and Hellman were right about the trend.

In 1997, a volunteer effort called DESCHALL recovered a DES key in 96 days using the idle time of tens of thousands of Internet-connected computers. In July 1998, the Electronic Frontier Foundation, a civil liberties organization, unveiled a purpose-built machine called Deep Crack, containing 1,856 custom chips and built for under $250,000. It found a DES key in 56 hours. In January 1999, Deep Crack, working with a distributed network of volunteers, found one in 22 hours and 15 minutes. The U.S. government was still claiming that DES was adequate, and the EFF wanted to demonstrate, for a quarter of a million dollars, that the claim was false.

The 64-bit block is the other limit. There are only \(2^{64}\) possible blocks, so two blocks encrypted under the same key can be expected to collide after about \(2^{32}\) blocks, or 32 gigabytes. This is the same birthday reasoning that makes a shared birthday likely in a room of 23 people: among \(N\) equally likely values, a repeat is expected after about \(\sqrt{N}\) draws, and \(\sqrt{365}\) is about 19 while \(\sqrt{2^{64}} = 2^{32}\). In CBC mode, described below, two equal ciphertext blocks reveal the XOR of two plaintext blocks. A 2016 attack called Sweet32 used this to recover a session cookie from a long-lived HTTPS connection encrypted with a 64-bit block cipher after capturing several hundred gigabytes of traffic.

Triple DES

Replacing DES took twenty years, and in the meantime, the industry extended its life by running the encryption three times. Triple DES (3DES) encrypts with one key, decrypts with a second key, and encrypts again with a third, an arrangement written EDE:

\[C = E_{K_3}(D_{K_2}(E_{K_1}(P)))\]

Here \(E_K\) and \(D_K\) are encryption and decryption under key \(K\). The decrypt in the middle is for backward compatibility: with all three keys equal, the first two operations cancel and the result is ordinary DES. Encrypting twice with two keys would have been cheaper, but a meet-in-the-middle attack, which works from both ends of a double encryption at once, makes two keys barely stronger than one. (The attack is described in the appendix.) With three independent keys, the key length is nominally 168 bits, but the same attack reduces it to about 112 bits of security. With only two distinct keys (\(K_3 = K_1\)) the strength is at most 112 bits and, against an attacker who has collected many known plaintexts, closer to 80. Both are beyond the reach of a brute-force attack, but not by the margin that the key lengths suggest.

3DES kept the 64-bit block and ran at one-third the speed of a cipher that was already slow in software. It was an interim solution, and it protected an enormous amount of traffic, including most of the world’s card payment systems, for two decades. NIST deprecated it in 2017 and disallowed it for encryption after 2023.

AES

In January 1997, NIST announced an open competition to replace DES. The rules were unusual for a government agency. Any team anywhere in the world could submit a design. The designs and all analysis would be public, and the winner would be chosen after several years of open cryptanalysis by the research community.

Fifteen candidates were accepted in 1998, and five finalists were chosen in 1999: MARS, RC6, Rijndael, Serpent, and Twofish. In October 2000, NIST selected Rijndael, designed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen. It was published as the Advanced Encryption Standard (AES) in November 2001.

Rijndael is a family of ciphers that supports several block and key sizes. AES is a member of that family with a 128-bit block and a key of 128, 192, or 256 bits, using 10, 12, or 14 rounds, respectively. The larger block eliminated the birthday problem that limited DES: \(2^{64}\) blocks under one key is 256 exabytes, more than any key will ever encrypt.

The AES Round

AES holds its 128-bit state as a 4 by 4 grid of bytes, and each round applies four operations to it:

1. SubBytes replaces each of the 16 bytes using a single fixed S-box, a 256-entry table chosen for its resistance to the differential and linear attacks described below. This adds confusion.

2. ShiftRows rotates each row of the grid by a different amount: row 0 stays put, row 1 moves one byte to the left, row 2 moves two, and row 3 moves three. Bytes that were in the same column are now spread across four columns.

3. MixColumns replaces each column with a linear combination of its four bytes, so that a change to any byte in a column affects all four. Together with ShiftRows, this is diffusion: after two rounds, every byte of the state depends on every byte of the input.

4. AddRoundKey XORs the round key into the state.

The final round omits MixColumns, which simplifies decryption without weakening the cipher. Decryption applies the inverse of each step in reverse order. The whole cipher can be written in a few hundred lines of code, and the S-box and the MixColumns matrix are the only large tables.

Why Rijndael Was Selected

Rijndael was selected for its combination of security and speed. Its operations work on bytes and 32-bit words rather than on individual bits, so it runs fast on ordinary processors, on 8-bit smart cards, and in hardware. Its structure is regular enough that the designers could publish a mathematical argument for its resistance to differential and linear cryptanalysis, both described below, rather than relying on a large number of rounds.

After more than a quarter-century of analysis, no practical attack on AES has been discovered. The best-known attack on the full cipher, published in 2011, recovers an AES-128 key with about \(2^{126}\) operations, which is a factor of four better than brute force and of no practical use. Attacks on versions with fewer rounds exist, and they are used by the research community to measure the security margin. In 2003, the U.S. government approved AES for classified information up to Top Secret, the first time a public cipher had been approved for that purpose.

Intel processors have included AES-NI, a set of instructions that perform an AES round in hardware, since 2010, and AMD processors since 2011. ARM processors have equivalent acceleration support. Hardware AES runs at several gigabytes per second per core and, because it does not use lookup tables, it is immune to the cache-timing attacks described below. On any processor with these instructions, AES is both the fastest and the safest choice.

Modes of Operation

A block cipher accepts only one relatively small fixed-size block, so it does not specify how to encrypt a longer message. Applying it independently to every block would also map identical plaintext blocks to identical ciphertext blocks. A mode of operation specifies how to apply a block cipher across an entire message. It determines whether repeated plaintext blocks produce repeated ciphertext blocks, whether the final block needs padding, whether blocks can be processed in parallel, and whether changes to the ciphertext can be detected. Choosing the wrong mode breaks the system even when the cipher is perfect.

Many modes require a value that changes from one message to the next, in addition to the secret key. This value is public. Changing it allows the same plaintext to produce different ciphertext each time it is encrypted.

A nonce, short for “number used once,” is a per-message value that must not repeat under the same key. An initialization vector (IV) supplies the starting value a mode uses before processing the first plaintext block. The terms are sometimes used interchangeably, and each mode specifies the input it requires. A mode may require an IV to be unpredictable, to never repeat for the same key, or both. Nonces and IVs normally travel with the ciphertext and do not need to be secret.

We will cover integrity in detail later, but one distinction is needed here because it affects the choice of encryption mode. Confidentiality hides a message’s contents, while integrity detects unauthorized modification. A short authentication tag allows a receiver to verify whether the encrypted data has been altered.

Modes that provide confidentiality without a tag do not prevent an attacker from altering ciphertext. Such ciphertext is malleable: an attacker can modify it to cause a predictable change in the plaintext, without knowing the key. ECB, CBC, and CTR are all malleable, each in its own way. An authenticated encryption with associated data (AEAD) mode produces an authentication tag along with the ciphertext, and the receiver rejects any message whose tag does not verify. For now, an AEAD mode can be understood as encryption along with a built-in tamper check. The advantage over encrypting and then adding a separate integrity check is that one key and one operation do both, so there is no second algorithm to choose and no way to combine the two steps in the wrong order.

In the formulas below, \(P_i\) is plaintext block \(i\), \(C_i\) is the corresponding ciphertext block, and \(E_K\) is encryption of one block with the cipher under key \(K\).

Electronic Codebook

A codebook, in the traditional sense, is a printed book that lists words and phrases beside the code groups that replace them. A clerk looks up each word independently, and the same word produces the same code group every time until the book is replaced. Electronic codebook (ECB) mode applies that idea to blocks. Each block is encrypted independently with the same key:

\[C_i = E_K(P_i)\]

There is no printed book with \(2^{128}\) entries, since the cipher and the key compute the lookup, but the result has the codebook’s defining property. If \(P_i = P_j\), then \(C_i = C_j\). The same plaintext block always produces the same ciphertext block, wherever it appears in the message and however many messages share the key. ECB is the most basic mode, and it provides no protection beyond the block cipher itself.

Because each block goes through the cipher as a unit, the message must be a whole number of blocks. A shorter message is extended with padding to fill the last block, usually by appending \(n\) bytes each with value \(n\), which the receiver strips after decryption.

ECB hides the contents of each block but not the pattern of blocks. The image shown here is the Linux mascot after every 16-byte block of the picture was encrypted with AES in ECB mode. Every uniform region became a different uniform texture, and the outlines remained visible. Encrypting a database column reveals which rows share a value. An attacker who cannot read a single block can still delete, duplicate, or reorder blocks, and the receiver has no way to notice.

In October 2013, Adobe lost a database of 153 million user records to attackers. The passwords had been encrypted with 3DES in ECB mode, and because identical passwords produced identical ciphertext, the most common ciphertext value appeared 1.9 million times. Users had also stored unencrypted password hints, so a hint of “one to six” next to the most common value identified it as 123456 and, with it, every other account that used that password. ECB is acceptable for encrypting a single block, such as a key. It should not be used for data.

Cipher Block Chaining

The problem with ECB is that each block is looked up independently. Cipher block chaining (CBC) mode breaks that independence by making each block’s encryption depend on all preceding blocks. Each plaintext block is XORed with the previous ciphertext block before it is encrypted:

\[C_i = E_K(P_i \oplus C_{i-1})\]

Identical plaintext blocks now produce different ciphertext because what came before them differed. The first block has no predecessor, so it is XORed with an IV in place of \(C_0\). For CBC, the IV must be unpredictable: a fresh block of random bits for each message, sent along with the ciphertext.

Because two equal ciphertext blocks mean that the plaintext blocks differed by exactly the XOR of the two preceding ciphertext blocks, a block collision in CBC leaks plaintext, which is what Sweet32 exploited.

CBC was the standard mode for thirty years, but it has drawbacks:

1. Encryption cannot be parallelized, since each block depends on the previous block.

2. It hides the plaintext but does not detect changes to the ciphertext.

3. Flipping one bit of a ciphertext block corrupts that block’s plaintext and flips the same bit in the next block’s plaintext, a predictable effect that an attacker can use. This follows from decryption, \(P_i = D_K(C_i) \oplus C_{i-1}\): the previous ciphertext block is XORed in after the cipher runs, so a bit flipped in \(C_{i-1}\) never passes through the cipher on its way into \(P_i\). Diffusion scrambles \(P_{i-1}\), which came from decrypting the altered block, but not \(P_i\).

Moreover, its handling of padding has been the source of a long line of attacks. The first, published in 2002, targeted a server that reported whether the padding of a modified ciphertext was valid. Those reports were enough to decrypt the ciphertext one byte at a time, and an attack of this kind is now called a padding oracle.

Counter Mode

CBC chains each block to the previous one, forcing encryption to run in sequence and requiring padding. Counter (CTR) mode takes a different approach: instead of encrypting the plaintext, it uses the block cipher to generate a keystream, a long pseudorandom sequence of bits, and XORs that with the plaintext the way a one-time pad does. The keystream comes from encrypting a sequence of counter values, one per block:

\[C_i = P_i \oplus E_K(\mathit{counter}_i)\]

Each counter value is built from the message’s nonce and the block number. Because each counter value is encrypted independently, encryption and decryption can be parallelized, and any block can be decrypted without touching the others. No padding is needed, since the last keystream block can be truncated.

The requirement is that no counter value is ever encrypted twice under the same key, which means the nonce must never repeat. If it does, two messages are XORed with the same keystream, and the one-time pad’s key-reuse failure follows immediately: XORing the two ciphertexts yields the XOR of the two plaintexts. This is not just a theoretical concern. In 2017, the KRACK attack on WPA2, the protocol that secures nearly every Wi-Fi network, tricked a client into reinstalling its key, which reset the nonce counter and made the keystream repeat.

CTR mode is malleable in the most direct way. Because ciphertext is plaintext XOR keystream, flipping one bit of the ciphertext flips exactly that bit of the decrypted plaintext, and the receiver has no way to detect the change. CTR, therefore, has to be paired with authentication, and the standard way to do that is the mode described next.

Galois/Counter Mode

Galois/Counter mode (GCM) is CTR mode with an authentication tag added, computed by fast polynomial arithmetic over the ciphertext and any unencrypted header data. That header data is the “associated data” in the name AEAD: information such as a packet’s addresses, a protocol version, or a sequence number that must remain readable in transit but must not be altered. GCM authenticates it without encrypting it. Any change to the nonce, associated data, ciphertext, or tag causes verification to fail, and a correct implementation reports a single generic failure and releases no plaintext. GCM is the most widely used AEAD mode and the default in TLS 1.3, the protocol that secures most web traffic.

GCM uses a 96-bit nonce, and a repeated nonce is worse here than in plain CTR mode. In CTR mode, a repeated nonce causes the keystream to repeat and exposes the XOR of the two plaintexts. In GCM it also leaks the internal value used to compute the tags, after which an attacker can forge tags for their own messages. The nonce can be a counter, which guarantees uniqueness as long as the counter is stored and updated correctly, or a random value. Random 96-bit values will eventually collide, so a random nonce imposes a limit on the number of messages that can be sent under a single key. Whichever is used, the library or protocol should generate the nonce. Application code that constructs its own nonces is a common source of failures.

Choosing a Mode

The four modes differ in what they need and what they provide:

For new systems, use an AEAD mode to detect tampering. If the platform has AES hardware, use AES-GCM. If it does not, use ChaCha20-Poly1305, described below. Treat the nonce or IV as part of the design, and never reuse one under the same key. Most failures of symmetric encryption stem from one of three mistakes: using ECB when an authenticated mode was needed, reusing a nonce, or failing to authenticate the ciphertext.

Stream Ciphers

CTR mode makes a block cipher behave as a stream cipher. A native stream cipher drops the block cipher and builds a keystream generator directly: a function that takes a secret key and a nonce and produces a long sequence of pseudorandom bits, which the cipher XORs with the plaintext. Decryption regenerates the same keystream and XORs again.

A stream cipher is a practical imitation of the one-time pad. The pad XORs the message with a truly random key as long as the message and achieves perfect secrecy. A stream cipher replaces that key with a pseudorandom keystream expanded from a short key, so its security is computational rather than perfect, and the pad’s rules still apply: the keystream must never be reused and must not be predictable.

The keystream generator is a CSPRNG (cryptographically secure pseudorandom number generator), and the security of the cipher is entirely the security of the generator. If any part of the keystream can be predicted from any other part, the cipher is broken, and, as with CTR mode, a nonce that repeats under the same key repeats the keystream. A stream cipher on its own is malleable for the same reason CTR mode is, so it too needs authentication.

RC4

For about twenty years, the stream cipher on the Internet was RC4, designed in 1987 by Ron Rivest of RSA Security. It was a trade secret until someone posted its source code to a mailing list in 1994. After that, it was widely adopted in SSL and TLS, the WEP and WPA wireless standards, and Microsoft Windows. It is a few dozen lines of code, and it was very fast, but its keystream is biased. The first bytes of the RC4 keystream are measurably nonrandom, and a 2001 attack on the way WEP combined RC4 with its per-packet key let attackers recover a wireless network’s key from captured traffic. Attacks on RC4 in TLS followed, and in 2015, the standards body for Internet protocols prohibited its use in TLS.

ChaCha20

ChaCha20, designed by Daniel Bernstein in 2008, is the stream cipher that replaced RC4. It is built from additions, rotations, and XORs on 32-bit words, operations that take the same time regardless of their operands and use no lookup tables, so an implementation leaks nothing through the timing and cache side channels described below.

As standardized for Internet protocols, ChaCha20 has a 256-bit key, a 96-bit nonce, and a 32-bit counter. Its keystream is produced the same way CTR mode produces one, except that no block cipher is involved: ChaCha20 mixes the key, nonce, and counter together to produce 512 bits of keystream, then increments the counter and repeats.

ChaCha20 is nearly always paired with Poly1305, an authenticator also designed by Bernstein, in an AEAD construction called ChaCha20-Poly1305. Google adopted it in Chrome and Android in 2014 because most phones at the time lacked AES hardware, and ChaCha20 ran about 3 times faster than AES in software. It is now one of the standard cipher choices in TLS 1.3, alongside AES-GCM, and the two are used to encrypt nearly all web traffic.

Ciphers in Current Use

Four ciphers account for nearly everything a programmer will encounter:

Other block ciphers appear in national standards and older software, such as China’s SM4, Japan’s Camellia, and Russia’s Kuznyechik. None is known to be weak, but there is no reason to choose one over AES for new work.

Cryptanalysis of Modern Ciphers

A brute-force attack against a 128-bit key is not a concern. Trying \(2^{128}\) keys at a billion billion per second would take nearly a thousand times the age of the universe. A cryptanalytic attack is any method that recovers the key, or the plaintext, in fewer operations than brute force. The three families below have produced results against real ciphers.

Differential Cryptanalysis

Differential cryptanalysis studies how a difference between two plaintexts propagates through the cipher into a difference between the two ciphertexts. The attacker chooses pairs of plaintexts that differ in a specific bit pattern, obtains their encryptions, and looks for output differences that occur more often than chance would predict. In a perfect cipher, every output difference would be equally likely. In a real cipher, the S-boxes exhibit input differences that produce output differences with elevated probability. An attacker who can trace a high-probability path of differences through most rounds can use the last round to test guesses for key bits.

The attack needs chosen plaintexts, and a great many of them. Against full 16-round DES, it needs \(2^{47}\) of them, which is why DES was never broken this way outside a laboratory. Its importance was that it gave designers a design criterion. Every serious cipher design since 1990 has had its S-boxes and its diffusion layer chosen so that no difference path survives more than a few rounds with useful probability. AES was designed with a proof of that property.

Linear Cryptanalysis

Linear cryptanalysis looks for the opposite kind of weakness. An S-box is nonlinear, but it may be approximately linear: some XOR of a few input bits may equal some XOR of a few output bits slightly more or less than half the time. Chaining such approximations across the rounds gives an equation relating plaintext bits, ciphertext bits, and key bits that holds with a probability slightly different from one-half. With enough known plaintext and ciphertext pairs, the bias becomes measurable, and the equation may reveal key bits.

Mitsuru Matsui’s attack on DES, published in 1993, needed \(2^{43}\) known plaintexts, and he ran it on twelve workstations for fifty days in 1994. It was the first experimental break of full DES by any method other than brute force. Like differential cryptanalysis, its lasting effect was on design: modern S-boxes are chosen to have the smallest possible linear bias, and AES’s designers published bounds on how far any linear approximation could propagate.

Side-Channel Attacks

A side-channel attack ignores the mathematics and attacks the implementation. Any physical quantity that varies with the secret can be measured and correlated with the key: how long an operation takes, which memory addresses it touches, how much power the chip draws, or what electromagnetic noise it emits. These attacks have recovered keys from implementations of every cipher discussed here.

Several kinds are in regular use:

• Timing and cache attacks. A software AES implementation that uses lookup tables indexed by bytes of the state touches memory locations that depend on the key. On a shared machine, another process can watch which cache lines were loaded and infer those bytes. In 2005, Daniel Bernstein recovered a full AES key over a network by timing a server’s responses.

• Power analysis. The current a chip draws varies with the bits it is processing. Paul Kocher showed in 1998 that statistical analysis of a few thousand power traces from a smart card could recover its DES key. Power analysis remains the standard test of any hardware that holds a key.

• Fault injection. A short glitch in the supply voltage or clock, or a laser pulse aimed at the chip, causes a computation to go wrong, and the difference between the faulty output and the correct one can reveal the key. One or two faulty AES ciphertexts, with the fault injected in the right round, are enough.

Defenses remove the correlation between the secret and the measurement. Constant-time code has no branches and no memory accesses that depend on secrets, so that timing and cache behavior are the same for every key. Hardware instructions such as AES-NI are constant-time by construction. Masking XORs a fresh random value into every intermediate result so that the power trace correlates with the mask rather than the secret.

Quantum Computers

A large quantum computer could change these calculations. Grover’s algorithm, published in 1996, searches an unstructured space of \(N\) items in about \(\sqrt{N}\) steps. It would cut the effective length of a symmetric key in half. A cipher offers \(n\) bits of security when the best attack costs about \(2^n\) operations, so AES-128 would offer 64 bits of security, and AES-256 would offer 128. That is why AES-256 is now recommended for data that must stay secret for decades. Symmetric cryptography survives quantum computing with a longer key. Public-key cryptography, the asymmetric kind mentioned at the start of these notes, does not, and we will cover that problem in detail later.

Requirements for a Secure Cryptosystem

Over fifty years of open cryptographic research have established what a symmetric cipher and its surrounding system must provide:

• Security that survives disclosure. The algorithm is public and depends only on the key. A product that relies on a proprietary or secret cipher violates Kerckhoffs’s principle.

• Ciphertext that reveals nothing about which message was encrypted. This is the indistinguishability standard from the previous part. One consequence is that encrypting the same message twice under the same key must produce two different ciphertexts, which is why every mode but ECB takes a nonce or IV.

• No shortcut to the key. The best known attack is brute force, or close enough that the difference is irrelevant.

• A key long enough that brute force is infeasible. 128 bits is the minimum, and 256 bits is recommended for long-lived secrets.

• Security under chosen-plaintext and chosen-ciphertext attacks. A sound cipher with a fresh nonce for every message provides the first. An AEAD mode provides the second: an altered ciphertext fails its tag check and is rejected before decryption, so an attacker learns nothing by submitting one.

• Resistance to side channels. Constant-time implementations or hardware instructions.

• A fresh IV or nonce for every message under a given key.

• Keys that are generated, stored, and destroyed properly. Keys come from the operating system’s CSPRNG, never directly from a password or a timestamp. They stay out of logs, crash dumps, and source code. Separate purposes get separate keys, and a key is replaced before it reaches the limit on messages or data that its mode allows.

Most of these are properties of the surrounding system rather than of the cipher, and the failures in these notes bear that out:

• The Vigenère cipher was broken through key reuse.

• Enigma was broken through its operating procedures.

• The VENONA traffic was read because of a printing plant’s mistake.

• Adobe’s passwords were exposed by a mode of operation.

• The Debian keys were broken by two disabled lines of code.

AES itself has not been broken. A system can use AES-256 with a perfectly random key and still give up its messages because two virtual machines were restored from the same snapshot and resumed with the same nonce counter. The general rule is to use a well-reviewed library’s AEAD interface, let it generate the nonces, and spend the effort saved on key management.

Lecture 2: Part 1 | Part 2 | Part 3 | Part 4 | Appendix