Fondos de inversión éticos y otros productos de riesgo

We know that there is no exhaustive, officially known answer to this question. Only the types of attacks against DES are known:

• brute-force,

• differential, and

• linear cryptanalysis.

We will discuss all three types below and, on this occasion, learn a new crypt- analytic method.

4.4.1

Brute-Force Attack and the ‘Deep Crack’ Computer

The only practicable attack against DES is brute force, i.e., trying all 256 _pos- sible keys. This is a huge number: the ciphertext has to be decrypted and

tested for about 72 000 000 000 000 000 or 72 quadrillion keys to produce some meaningful plaintext.

4.4. How Secure is DES? 141

A large number of estimates can be found in the literature as to which computers would be busy for how long and, mainly, how much a special computer that could handle this task within meaningful time would cost. In 1993, for example, the price of a machine used for a 3.5-hour brute-force attack was estimated to be one million dollars [SchnCr, 1.27; GarPGP, Chapter 3, ‘DES Cracking’]. Of course, this estimate is old hat: a mention at EUROCRYPT ’98 reduced this hypothetical time to half an hour (at the same price). A 40-bit DES key could be found in 50 ms.

The RSA Challenge

Since nobody built such a machine, people fell back on available resources, namely idle times of computers on the Internet. To this end, RSA Data Security, Inc. started an initiative calledRSA Challenge, where a brute-force attack was distributed over innumerable computers. When a DES key was found (the search took from January to June 1997), RSA started a second initiative, which was successful in February 1998 after only 39 days. In this initiative, about 22 000 users all over the world had put to work more than 50 000 processors (CPUs) for this task, and tried 85 % of all possible keys before the correct one came up. You can find all the details on the RSA Web site at www.rsa.com. ‘What’s all this good for?’, you might ask. Brute force is nothing to write home about these days, and all this computer capacity wasted! Not really, for the following reasons:

• First, computers worked at this task only when they were not busy oth- erwise so that no valuable computation time was wasted. (In fact, most computers are jobless during the largest part of their lives.)

• Second, the initiative gained valuable experience with distributed pro- cessing in large projects.

• Third and most importantly, the initiative was able to demonstrate to outsiders, too, that DES is no longer as secure as its supporters claim. This, in turn, had an immediate impact on the US export policies for cryptographic products so that eventually all of us profited.

The initiative’s first impact, however, looked more like a backfire: in February 1998, an expert declared before US Congress that, while this RSA Challenge was an impressive proof of how secure DES really was, it also showed that this approach was inappropriate for practical, unnoticed cryptanalysis. All this

whereas the initiative’s purpose was to show that a DES cracking machine could be built at all if only one had enough financial means.

How Deep Crack Was Born

The Electronic Frontier Foundation (EFF; www.eff.org) put an end to all speculation and doubts about potential DES cracking machines when it built such a machine. And not only that: the organization published a book [EFF] that describes how it’s built, disclosing the chip design and the firmware, printing the listings in scanner-friendly layout, and on top of it all, writing ‘Scan This Book!’ on the cover (the paper version had its reason in a loophole in the US laws, prohibiting the export over the Internet and on electronic media, but leaving out print media). No doubt this book had been intended to move things, and it really did.

In view of the hardware friendliness of DES, it came as no surprise to experts that such a machine could be built, but the implementation of the idea called Deep Crackis interesting nevertheless.

The actual surprise was how inexpensively such a machine could be built: a team of about ten people worked on it for little over 18 months, and not even full-time. The required control software came from voluntary work in less than three weeks. Altogether, the costs for design and testing were roughly 80 000 dollars, and 130 000 dollars were spent on material. The ‘total price’ of the project is usually stated to amount to 250 000 dollars. Series produc- tion of the machine would naturally be much cheaper. Advanced Wireless Technologies (AWT), the developers of the special chips, have started offering the machine for sale. Much faster special computers are no utopia either. An article in the magazine Information Week [InfWeekDES] assumes somewhat higher costs and estimates a write-off time of three years for the computer. With the one-million-dollar machine mentioned above (which could find a key within half an hour), the costs would be approximately 20 dollars per DES key. In other words, this could mean, for example, that the DES encryp- tion of an email (for instance using PEM in the current form, which is the PGP counterpart) would be worthwhile if the message were worth 20 dol- lars at most. But such values are usually underestimated. Cruel irony: the very same magazine had offered free annual subscription (worth 150 dol- lars) over a lengthy period of time to people who’d fill out a ‘harmless’ questionnaire. So much for how much people are really willing to pay for information.

4.4. How Secure is DES? 143

The Innards of Deep Crack

What do the parameters of the machine look like? Its core is a 40-MHz special chip with 24 independent search units, each of which manages one DES decryp- tion within 16 clock pulses. Sixty-four such chips are housed on one board. There are 12 such boards, plugged into scrapped Sun 4/470 computer boxes, and two such computers work in parallel. This results in a search speed of approximately 90 billion keys per second, i.e., roughly 2.5 times faster than the entire free capacity on the Internet that had been deployed for the RSA Chal- lenge! Each chip tests concurrently for certain criteria to find whether or not the plaintext created is meaningful, and stops when hitting a success. A control computer running Linux or Windows95 is responsible for further evaluation, and continues the search, if need be. The average search time is 4.5 days. Of particular interest is the test on plaintext, i.e., whether or not a tested key is the correct one. The hardware doesn’t find the correct key itself; it rather tests, for example, to see whether the plaintext created consists only of characters from a certain subset, for instance ASCII characters. If this is true, then a second ciphertext block (consisting of 8 bytes) is decrypted instantly, and the test is repeated. If this test is positive, too, then the search unit stops and informs the controlling PC which, in turn, takes over and runs further analyses. This means that the hardware is not responsible for finding the correct key, but for singling out as many ‘bad’ keys as possible! As a sideline, the machine also works with texts encrypted in CBC mode (see Section 5.1.1). Remember this ‘gradual filtering’ of a data stream. National intelligence organizations also work by this principle. We will get back to this issue in Chapter 8.

Meanwhile, there is at least one official successor: Copacobana (www. copacobana.org), which stands for ‘Cost-Optimized Parallel Code Breaker’,

is a machine with an FPGA basis developed jointly by the universities at Kiel and Cologne, Germany. You can buy it for 8980 euros (probably not in the supermarket though). It can handle about 48 billion DES ciphers per second, while consuming only 600 watts. This means that searching the full key space would take about nine days. It can also be used to break other block ciphers programmed in FPGA.

Other Considerations

It may be reasonably expected that DES cryptanalysis will be offered as a service unofficially. So you’ll have to strike out the sentence that can still be

Figure 4.11: The Copacobana DES cracking machine (from www. copacobana.org, Gallery, with the courtesy of the authors).

read quite often: DES is not secure against national intelligence agencies and large organizations. I tend to rewrite this sentence to read:

Don’t use DES for encryption if a party interested in the plaintext would be willing to pay a three-figure or four-figure sum. (The money amounts estimated really include all ‘expenses’; otherwise we would have to speak of a two-figure sum.)

Nobody doubts that the key length of 56 bits instead of 128 bits came about at the request of the NSA. We can guess why. However, this corresponded to the situation in place 20 years ago! There is much speculation as to whether and how the NSA cracks DES. Rumors have it that the NSA disposes of devices the size of small suitcases that handle such tasks in a matter of seconds.

Alternative Methods

With everything said above, we could actually shelve the ‘DES cryptanalysis’ topic. A real vulnerability hasn’t been found to this day; all that remains is brute force, and this is something that can be done today. All other attempts at breaking DES merely promoted the theory, and were practically unusable. But the theory is decisive in evaluating new algorithms with slightly larger key lengths, where brute force won’t do the trick. For this reason, we’ll stay with this topic a bit longer.

For example, it would be possible to use very large optical memories with values computed in advance. In the ‘simplest’ case, an attacker would have to

4.4. How Secure is DES? 145

determine and store all 72 quadrillion ciphertext blocks that can be formed by encrypting a frequent plaintext block. Such a plaintext block could contain eight zero bytes, for example (they certainly occur often enough, e.g., in WordPer- fect; see Section 3.5). In this case, the plaintext block assumes the role of the probable word we know from earlier sections. This would be less simple tech- nically: since the ciphertext blocks are 8 bytes long, we need about 850 million CDs to store them. When using 100-GB magnetic tapes, there would ‘only’ be about five million tapes. The media required can be further reduced when using new (e.g., holographic) methods. But things can be done far more thriftily. Time – Memory Tradeoff

This is a brute-force method developed by Hellman in 1980 [Hell.troff; Denn83, 2.6.3] with a rather complicated name: it means that we aim at achieving a tradeoff between time and memory. This method is not limited to DES; it can be applied to any encryption method. This means that it is a general cryptanalytic method.

The time–memory tradeoff is a refinement of the plaintext attack mentioned earlier. The trick is to store just a small part of the possible ciphertexts of a frequent plaintext rather than all of them. The rest is computed during the analysis. In detail, this looks as follows:

Assume we have a frequent plaintext block, P, the corresponding ciphertext, C, and some (very easy to compute) function,R, which maps the 64-bit blocks to 56-bit blocks. For example,Rcan be a rule which says that the most signif- icant bits should be truncated from the 8 bytes that form the 64-bit block. The following function is then defined for each 56-bit key,S:

f(S) = R(ES(P))

whereES(P )is the encryption ofP with keyS(E =encryption). We look for

all keys, S, in such a way that

f(S) = R(C)

Such anS can already be the key searched, but not necessarily, since eight bits are not tested. To search for this S, we randomly select m keys, S1, . . . , Sm,

and compute the following table with t columns and m rows for a given width,t:

S1 f(S1) f2(S1) = f(f(S1)) ... ft(S1)

...

Sm f(Sm) f2(Sm) = f(f(Sm)) ... ft(Sm)

This means that each element comes into being by removing eight bits from an encryption of the fixed plaintext, P, and serves as key for the element to the right of it. But we discard all intermediate results and store only the first and last columns.

Next, we look for our ciphertext, R(C), reduced to 56 bits, in the right-hand column. If we find it there in rowk, thenR(C)came into being by the encryp- tion ofP (and subsequent reduction,R), together with the key located in rowk of the table, columnt−1. That’s how we built the table in the first place. We can compute this key, since we had also storedSk; we ‘only’ have to transform

it (t−1) times by using function f.

If we don’t find R(C) in the last column, we might find it in the last column but one. IfR(C)is there, thenf (R(C))should occur in the last column of the table. So, let’s look for f (R(C)) in the last column. Now we can understand why we built the table in exactly this way. Our approach is then relatively easy in theory:

• Compute the table and store only the first and last columns.

• Search forR(C) in the last column.

• If not found, search for f (R(C))in the last column.

• If not found there either, search for f (f (R(C)) in the last column.

• . . .

• If found, compute the table element in the same row, but one column earlier.

The method doesn’t necessarily lead to the goal, but it’s very likely that it does. It ranges roughly in the middle between the usual brute-force attack (which tests all possible keys) and the dictionary attack (which tests only probable keys). In practice, we would create many tables in parallel (since the left columns are random) and select the m and t values such that the probability of being successful is sufficiently large, despite potential ‘false alarms’: after all, we test only 56 out of 64 bits for a match with the ciphertext block. The method can be made faster; see [Denn83, 2.6.3].

4.4. How Secure is DES? 147

We can see that, depending on what we select for m, t, and the number of tables, we can decide ourselves what we want to focus on: if we have plenty of storage available, we can select largemand number of tables; if our computer is very fast, we can work with larget; hence the name of the method.

Hellman suggested one million tables with 100 000 rows each computed in par- allel and one million rounds per row (which could cover a maximum of 1017 or 100 quadrillion possible values—the key space has ‘only’ 72 quadrillion entries). All tables together would require a storage space of roughly one Tbyte (terabyte, corresponds to one trillion bytes, or one million Mbytes)—no prob- lem considering the size of current jukeboxes. We would need a 1-Gbit memory, i.e., 125 Mbytes. All PCs will have this capacity before long. Moreover, we would have to deploy 10 000 DES chips. That’s a bit harder. In 1980, Hellman estimated 4µs as the time required per encryption for one DES chip. That would have resulted in a computation time of well over a year.

Of course, current chips are much faster. The VM007 chip produced by VLSI Technology in 1993 can handle 25 million encryptions per second (that’s an improvement by a factor of 100 compared with 1980—when using a 32-MHz clock frequency—and by a factor of 10 compared with theDeep Crack chips). With a tenfold use of such DES chips (i.e., 100 000 units), the time–memory tradeoff could be done in half a workday. The time required for one-time table computation is twice that amount.

The encryption modes we will discuss in Section 5.1.1 allow us to push up the cost of this attack:

• The time remains the same when using the ECB mode and a known plaintext. The table can be computed once and for all, i.e., this time is negligible.

• In CBC mode, though the plaintext is known, it has to be deemed to be random. A new table has to be created for every attack so that the time involved triples.

• Things are similar with the CFB and OFB modes. However, we need to know two consecutive pairs of ciphertext blocks and plaintext blocks.

The purpose of the time–memory tradeoff is, however, to compute the table once (at high cost) for a specific plaintext block and then try to find the key in routine operations relatively quickly. In this constellation, encryption in CBC mode would be hindering.

My considerations about the computing time may even be underestimated. Who do you think can listen in on your DES code?

Visual Cryptanalysis

The heading of this section is the title of a paper published by the well-known cryptanalyst Adi Shamir, who introduced it at EUROCRYPT ‘98 [Shamvis]. The simplified basic statement might initially seem spooky: throw away all computer technology and buy yourself a high-resolution black-and-white neg- ative film for aerial photographs, a photographic developer, and a black-color spray can. How on earth would anybody be able to run a cryptanalysis with that sort of material?

Photographic films are suitable for parallel processing. Though the development of a film takes ages compared with electronic bit processing, the film contains a very large number of bits. We divide the film’s image field into as small areas as possible, which we will call ‘dots’ for the sake of simplicity. A black dot corresponds to value 1, a non-black dot to value 0. We use this mask to expose a second film, and the inverse bit pattern will form once we’ve developed this film—where there was a 1, there’s a 0 now, and vice versa. Logically, we have executed a NOT operation, but processed all ‘film bits’ in parallel.

In contrast, if we superimpose two or more films so they are exactly congruent, and use this bunch to expose another film, then a dot on this (bottom) film will turn black, provided there are only non-black dots on top of it. This corre- sponds to the NOR operation, written as∼(a|b) expression in C. If we expose consecutively rather than concurrently, we do a NAND operation:∼(a&b). Yes, we could even do a XOR operation by utilizing the solarization effect. This effect says that, when exposing the negative for too long, it will no longer be blackened, but remain white after the development. To do a XOR operation, we prepare two films with dark gray instead of black dots and expose them long