Author(s): Bruce Schneier

ISBN: 0471128457

Publication Date: 01/01/96

Previous | Table of Contents | Next |

Later in the article, Tuchman is quoted: “We developed the DES algorithm entirely within IBM using IBMers. The NSA did not dictate a single wire!” Tuchman reaffirmed this when he spoke on the history of DES at the 1992 National Computer Security Conference.

On the other hand, Coppersmith wrote [373,374]: “The National Security Agency (NSA) also provided technical advice to IBM.” And Konheim has been quoted as saying: “We sent the S-boxes off to Washington. They came back and were all different. We ran our tests and they passed.” People have pointed to this as evidence that the NSA put a trapdoor in DES.

NSA, when questioned regarding any imposed weakness in DES, said [363]:

Regarding the Data Encryption Standard (DES), we believe that the public record from the Senate Committee for Intelligence’s investigation in 1978 into NSA’s role in the development of the DES is responsive to your question. That committee report indicated that NSA did not tamper with the design of the algorithm in any way and that the security afforded by the DES was more than adequate for at least a 5–10 year time span for the unclassified data for which it was intended. In short, NSA did not impose or attempt to impose any weakness on the DES.

Then why did they modify the S-boxes? Perhaps it was to ensure that IBM did not put a trapdoor in DES. The NSA had no reason to trust IBM’s researchers, and would be lax in their duty if they did not make absolutely sure that DES was free of trapdoors. Dictating the S-boxes is one way they could make sure.

Very recently some new cryptanalysis results have shed some light on this issue, but for many years this has been the subject of much speculation.

*Weak Keys*

Because of the way the initial key is modified to get a subkey for each round of the algorithm, certain initial keys are **weak keys** [721,427]. Remember that the initial value is split into two halves, and each half is shifted independently. If all the bits in each half are either 0 or 1, then the key used for any cycle of the algorithm is the same for all the cycles of the algorithm. This can occur if the key is entirely 1s, entirely 0s, or if one half of the key is entirely 1s and the other half is entirely 0s. Also, two of the weak keys have other properties that make them less secure [427].

The four weak keys are shown in hexadecimal notation in Table 12.11. (Remember that every eighth bit is a parity bit.)

Additionally, some pairs of keys encrypt plaintext to the identical ciphertext. In other words, one key in the pair can decrypt messages encrypted with the other key in the pair. This is due to the way in which DES generates subkeys; instead of generating 16 different subkeys, these keys generate only two different subkeys. Each of these subkeys is used eight times in the algorithm. These keys are called **semiweak keys,** and are shown in hexadecimal notation in Table 12.12.

Table 12.11 DES Weak Keys | ||||
---|---|---|---|---|

Weak | Key Value | (with parity bits) | Actual Key | |

0101 | 0101 | 0101 | 0101 | 0000000 0000000 |

1F1F | 1F1F | 0E0E | 0E0E | 0000000 FFFFFFF |

E0E0 | E0E0 | F1F1 | F1F1 | FFFFFFF 0000000 |

FEFE | FEFE | FEFE | FEFE | FFFFFFF FFFFFFF |

Some keys produce only four subkeys, each used four times in the algorithm. These **possibly weak** keys are listed in Table 12.13.

Before condemning DES for having weak keys, consider that this list of 64 keys is minuscule compared to the total set of 72,057,594,037,927,936 possible keys. If you select a random key, the odds of picking one of these keys is negligible. If you are truly paranoid, you could always check for weak keys during key generation. Some people don’t think it’s worth the bother. Others say that it’s so easy to check, there’s no reason not to.

There is further analysis on weak and semiweak keys in [1116], and additional key patterns have been investigated for weaknesses. None have been found.

*Complement Keys*

Take the bit-wise complement of a key; that is, replace all the 0s with 1s and the 1s with 0s. Now, if the original key encrypts a block of plaintext, then the complement of the key will encrypt the complement of the plaintext block into the complement of the ciphertext block.

If *x’* is the complement of *x,* then the identity is as follows:

*E*_{K}(*P*) =*C**E*_{K}’(*P’*) =*C’*

This isn’t anything mysterious. The subkeys are XORed with the right half after the expansion permutation in every round. This **complementation property** is a direct result of that fact.

Table 12.12 DES Semiweak Key Pairs | ||||||||
---|---|---|---|---|---|---|---|---|

01FE | 01FE | 01FE | 01FE | and | FE01 | FE01 | FE01 | FE01 |

1FE0 | 1FE0 | 0EF1 | 0EF1 | and | E01F | E01F | F10E | F10E |

01E0 | 01E0 | 01F1 | 01F1 | and | E001 | E001 | F101 | F101 |

1FFE | 1FFE | 0EFE | 0EFE | and | FE1F | FE1F | FE0E | FE0E |

011F | 011F | 010E | 010E | and | 1F01 | 1F01 | 0E01 | 0E01 |

E0FE | E0FE | F1FE | F1FE | and | FEE0 | FEE0 | FEF1 | FEF1 |

Previous | Table of Contents | Next |