Protecting Against Eavesdroppers with Symmetric Cryptography - Implementing SSL/TLS Using Cryptography and PKI - page 41

bit of output. Again, rather than specifying this in code, you use a permutation
table as shown in Listing 2-10:

1 3 5 7

2 4 6 8

Figure 2-6: DES expansion function

Listing 2-10: “des.c” expansion table

static const int expansion_table[] = {
32, 1, 2, 3, 4, 5,
4, 5, 6, 7, 8, 9,
8, 9, 10, 11, 12, 13,
12, 13, 14, 15, 16, 17,
16, 17, 18, 19, 20, 21,
20, 21, 22, 23, 24, 25,
24, 25, 26, 27, 28, 29,
28, 29, 30, 31, 32, 1 };

After this has been XORed with the correct subkey for this round, it is fed
into the s-box lookup. The s-boxes are what makes DES secure. It's important
that the output not be a linear function of the input; if it was, a simple statistical
analysis would reveal the key. An attacker knows, for example, that the letter
“E” is the most common letter in the English language — if he knew that the
plaintext was ASCII-encoded English, he could look for the most frequently
occurring byte of output, assume that was an “E”, and work backward from
there (actually, in ASCII-encoded English text, the space character 32 is more
common than the “E”). If he was wrong, he could fi nd the second-most occur-
ring character, and try again. This sort of cryptanalysis has been perfected to
the point where it can be performed by a computer in seconds. Therefore, the
s-boxes are not permutations, rotations or XORs but are lookups into a set of
completely random tables.
Each six-bits of the input — the expanded right-half XORed with the sub-
key — correspond to four bits of table output. In other words, each six bits of input
is used as an index into a table of four-bit outputs. In this way, the expanded,
XORed right half is reduced from 48-bits to 32. The s-boxes are described in a
particularly confusing way by the DES specifi cation. Instead, I present them