Cryptanalytic Approaches

(but mostly unusable). To my knowledge, there are still no reliable estimates of the minimum effort a cryptanalyst has to invest to break a certain algo- rithm. (This is the subject of so-called complexity theory.) Consequently, the cryptographer has to test a new algorithm against all current cryptanalytic methods and ideally guess the unconventional thoughts of an attacker. Since the security of an algorithm is in the foreground, its cryptanalysis is the measure of all things. Of secondary importance are criteria like fastness, easy implemen- tation in hardware, etc. This means that cryptography grows out of extensive knowledge of cryptanalysis. You have seen enough examples that confirm this statement in Chapter 2. Just like theorem number One in cryptanalysis, ‘the adversary always knows your method’, there are two important theorems in cryptography:

1. It is virtually useless to want to develop a good encryption algorithm if you don’t have a clue about cryptanalysis.

2. You will never make it on your own to exhaustively analyze an encryp- tion algorithm. An algorithm should first be disclosed and then be dis- cussed worldwide.

So a cryptographer always has to also be a cryptologist, i.e., to master crypt- analysis.

Being more particular, the second point above holds true only for the part of the world that’s accessible to us, i.e., public cryptological research. One example is the National Security Agency (NSA), for example. NSA is the biggest employer of mathematicians in the world (unconfirmed estimates range between 30 000 and 40 000 employees), and it is totally sealed off against the outside. It goes without saying that the NSA employs the best cryptologists in the world, who mutually review their developments. However, their algorithms normally remain secret. The only exception might be theSkipjack algorithm of the Clipper chip (see Section 5.7.5). We have no idea what level the knowledge accumulated there has reached, but it’s likely to be an unexpectedly high level.

3.2

Cryptanalytic Approaches

Suppose we have received a ciphertext and know the encryption method, as agreed. How could we proceed?

• We first need information on the plaintext, i.e., the goal to be achieved: what language is the plaintext in (German, English, Chinese?); is it a file

created by a word processor (which word processor?); is it a compressed file (which compression program?); is it a piece of recorded voice or images? Each of these plaintexts has specific properties for which we can test (have we achieved the goal?), and which we will exploit as extensively as possible during the cryptanalysis.

Our attack will be much more difficult without this information. All that’s generally left to do is to try each of the text formats and see what specific guess would allow us to mount an attack. This approach requires extensive experience and the kind of software that is probably not available on the Internet.

• If we know the structure of the plaintext and find out that the method is not particularly simple (i.e., not really Caesar, substitution, or Vigen`ere), then we can look at the possible keys. There might not be that many pos- sibilities. For example, there would be approximately 300 million possible keys if, say, passwords were composed of only six uppercase letters. This number won’t pose any major problem to a fast PC. However, we have to come up with a few very fast plaintext tests. We will expediently test in several steps:

– To start with, let’s test the first 100 characters of the ‘plaintext’ created for forbidden characters.

– If this preliminary test was successful, let’s test roughly for letter fre- quencies.

– Next, we test for forbidden digrams.

– Then we run a comparison with a dictionary.

– Finally, we have to manually test the last 20 variants to see whether or not they are meaningful.

This brute-force method is typically applied against the Caesar cipher. You can test the text by simply looking at it. A statistical method that also supplies the shift right away, and that can be automated would be more elegant.

However, even the worst cryptologist understands so much of his trade today to choose an astronomically large number of possible keys. If fewer keys are used, then it is most likely one of the older methods, or there is some intention behind it (e.g., because NSA so requested, or a crack software vendor wants to make a living).

3.2. Cryptanalytic Approaches 67

possible keys practically used keys

dictionary key

Figure 3.2: Dictionary attack.

It is actually a cryptologist’s highest goal to design his algorithm so well that the cryptanalyst has to fall back on the brute-force method, for then the attacker has generally little chance.

• But we might not have to go that far. A dictionary attack might be sufficient. People often take the request ‘Enter your password’ literally and type a real password. In that case, ten thousand or hundred thousand attempts will do to recover the key. There are plenty of corresponding dictionaries available. This approach is appropriately called dictionary attack. We will discuss a qualified attack of this type in Section 3.3. Such reduced key spaces where the number of keys practically used is much smaller than the number of keys theoretically possible are serious ciphering errors. They are a major vulnerability in the symmetric methods discussed so far.

This shortcoming can be removed reliably by using random session keys (more about this in Chapter 4), or by crunching a passphrase such as with PGP (see Section 7.1.3).

• With methods working characterwise, which are most of the methods dis- cussed so far, we will often use statistical methods. There were plenty of examples in Chapter 2, and we will come back to this issue in Sections 3.5 and 3.6.

A prerequisite for such methods is the availability of sufficient statisti- cal material. In view of the ‘monster files’ that current word processors

create, there shouldn’t be a lack of material, as opposed to World War II when characters had been typed manually. With a file the size of one Mbyte, it is no longer helpful to change the key regularly—one Mbyte is enough for statistics.

• It might even be possible to mount a plaintext attack. There are many possibilities to do just that. Look at the following realistic approach: the staff in an office produce documents by given guidelines, including the mandatory use of specific style files or macro files. The entries in the file created are considerable; in fact, they can amount to umpteen Kbytes (together with all other style data, my letterhead in WordPerfect is 22 Kbytes long). It’s just a question of recovering the remaining Kbytes of confidential text. . .

However, the bombing of light buoys (Chapter 2) went out of fashion. There are better methods today.

• Testing for probable words is another special plaintext attack. In this case, all we know (or guess) is that a certain word occurs in the text, and perhaps we even know roughly where. We could start a plaintext attack for any possible position to recover the key, or at least part of it. We try to limit the number of possible positions by means of other methods, e.g., the negative pattern search described in Section 3.4.1.

• We could arbitrarily include other information about the plaintext in our analysis. Section 3.6.4 shows several examples.

• Not least, every program that poorly implements a good algorithm offers the cryptanalyst welcome vulnerabilities. Imagine that a ‘dead secure’ software package for encrypted data communication stores your key on the hard disk of a DOS or Windows computer, perhaps even without you knowing! (Or the encryption is faked. I noticed a curious example under Microsoft Word 6.0, when the text parts themselves obviously remained unchanged by ‘protecting the file’.) Such mishaps are bound to happen when a programmer knows nothing about cryptology.

• Finally all kinds of ciphering errors make an attacker’s life easier; see Figure 3.1. Since ciphering errors always happen in practice, there is only one way out, namely to prevent them from within the program. Therefore, a good algorithm always has to be resistant to plaintext attacks. Keys should be created by a program.

These are all rather blurred statements. Things will get more specific from the next section onwards. However, there is no general-purpose recipe as to

3.2. Cryptanalytic Approaches 69

• Information about the plaintext: Created by which program? What striking properties?

• Brute force: Trying the key space, if possible (important: quick testing for correct plaintext).

• Searching a reduced key space (common in practice; dictionary attack). • Plaintext attack: Fixed byte sequences in word processors; known formats of

database files, etc.

• Testing for probable words (special plaintext attack, especially for short files): experimenting, negative pattern search.

• Exploiting additional information about the plaintext: compressed file, ASCII text,. . .

• Exploiting any theory: In practice, it is usually a mix of algebra, number the- ory, and probability theory; the remainder can be handled by experimenting. • Exploiting vulnerabilities in the implementation: Inept ‘improvements’ or ‘simplifications’ of an algorithm, but also keys stored in unsafe places, trans- mitting a key in plaintext over an insecure network, etc.

Figure 3.3: Potential vulnerabilities for the cryptanalyst to exploit.

how a cryptanalyst should proceed. Even with an algorithm as primitive as the Vigen`ere method, cryptanalysis depends heavily on the plaintext expected so that one single deciphering program will never cover all practically thinkable cases. Nevertheless, people quite simply say that ‘Vigen`ere was broken’. The reason is that cryptanalysts may use any theory; the main thing is that it leads to success often enough. Should their crack programs not find a password occasionally—oh well, they can surely explain and get over it. The attacked algorithm remains insecure all the same. In contrast, the cryptographer who designed the algorithm is disgraced by one single successful attack. The cryp- tographer would actually have to cover himself against everything during the design, which is impossible, of course.

As long as complexity theory cannot supply provable minimum estimates of the effort required for cryptanalyzing an algorithm, the ‘cryptography versus cryptanalysis’ race will continue.