chap-1.html
ad78711229981da0d1087d87447fe4fd1515b11ed2d2dd2c30108971c18fa5ff<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<HEAD>
<TITLE>Cracking DES: Secrets of Encryption Research, Wiretap Politics, and
Chip Design </TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>
<A NAME="1">1</A>
</H1>
<H2>
<I>Overview</I>
</H2>
<P>
<I>In This chapter: <BR>
</I>
<UL>
<LI>
<I>Politics of Deception </I>
</UL>
<UL>
<LI>
<I>Goals </I>
</UL>
<UL>
<LI>
<I>History of DES Cracking </I>
</UL>
<UL>
<LI>
<I>EFF's DES Cracker Project </I>
</UL>
<UL>
<LI>
<I>Architecture </I>
</UL>
<UL>
<LI>
<I>Who Else Is Cracking DES? </I>
</UL>
<UL>
<LI>
<I>What To Do If You Depend On DES </I>
</UL>
<UL>
<LI>
<I>Conclusion </I><BR>
</UL>
<H3>
<I>Politics of Decryption </I>
</H3>
<P>
We began the Electronic Frontier Foundation's DES Cracker project because
of our interest in the politics of decryption.* The vulnerability of widely
used encryption standards like DES is important for the public to understand.
<P>
A "DES Cracker" is a machine that can read information encrypted with the
Data Encryption Standard (DES), by finding the key that was used to encrypt
it. "Cracking DES" is a name for this search process. It is most simply done
by trying every possible key until the right one is found, a tedious process
called "brute-force search".
<P>
If DES-encrypted information can easily be decrypted by those who are not
intended to see it, the privacy and security of our infrastructures that
use DES are at risk. Many political, social, and technological decisions
depend on just how hard it is to crack DES.
<P>
We noticed an increasing number of situations in which highly talented and
respected people from the U.S. Government were making statements about how
long it takes to crack DES. In all cases, these statements were at odds with
our own estimates and those of the cryptographic research community. A less
polite way to say it is that these government officials were Lying, incompetent,
or both. They were stating that cracking DES is much more expensive and
time-consuming than we believed it to be. A very credible research paper
had predicted that a
<P>
_______________
<P>
<SMALL>* DES, the Data Encryption Standard, encrypts a confidential message
into scrambled output under the control of a secret key. The input message
is also known as "plaintext", and the resulting output as "ciphertext". The
idea is that only recipients who know the secret key can decrypt the ciphertext
to obtain the original message. DES uses a 56-bit key, so there are
2<SUP>56</SUP> possible keys. </SMALL>
<P>
<I>1-1</I>
<P>
<HR>
<P>
<I>1-2</I>
<P>
machine could be built for $1.5 million, including development costs, that
would crack DES in 3-1/2 hours. Yet we were hearing estimates of thousands
of computers and weeks to years to crack a single message.
<P>
On Thursday, June 26, 1997 the U.S. House of Representatives' Committee on
International Relations heard closed, classified testimony on encryption
policy issues. The Committee was considering a bill to eliminate export controls
on cryptography. After hearing this testimony, the Committee gutted the bill
and inserted a substitute intended to have the opposite effect. A month later,
a censored transcript of the hearing was provided; see
<A HREF="http://jya.com/hir-hear.htm">http://jya.com/hir-hear.htm</A>. Here
are excerpts:
<P>
<I><B>Statement of Louis J. Freeh, Director, Federal Bureau of
Investigation</B></I>
<BLOCKQUOTE>
. . . And we do not have the computers, we do not have the technology to
get either real-time access to that information or any kind of timely access.
<P>
If we hooked together thousands of computers and worked together over 4 months
we might, as was recently demonstrated decrypt one message bit. That is not
going to make a difference in a kidnapping case, it is not going to make
a difference in a national security case. We don't have the technology or
the brute force capability to get to this information.
</BLOCKQUOTE>
<P>
<B><I>Statement of William P. Crowell, Deputy Director, National Security
Agency</I></B>
<BLOCKQUOTE>
. . . I would go further and say there have been people who have said that
Louis Freeh's organization should just get smarter technically, and if they
were just smarter technically, they would be able to break all of this stuff.
I would like to leave you with just one set of statistics, and then I think
I am going to close with just a few comments on the bill itself.
<P>
There is no brute force solution for law enforcement. [blacked out
----------------------------------------------] A group of students -- not
students -- the Internet gang last week broke a single message using 56-bit
DES. It took 78,000 computers 96 days to break one message, and the headline
was, DES has weak encryption.
<P>
He doesn't consider that very weak. If that had been 64-bit encryption, which
is available for export today, and is available freely for domestic use,
that same effort would have taken 7,000 years. And if it had been 128-bit
cryptography, which is what PGP is, pretty good privacy, it would have taken
8.6 trillion times the age of the universe.
</BLOCKQUOTE>
<P>
<HR>
<P>
<I>1-3</I>
<P>
<I><B>Comments made later in the hearing</B></I>
<BLOCKQUOTE>
Chairman Gilman. Would you need added manpower resource and equipment if
there is a need to decrypt? And would that add to your already difficult
case of language translation in many of your wiretaps?
<P>
Director Freeh. We would certainly need those resources, but I think more
importantly is the point that was made here. Contrary to the National Research
Council recommendation that the FBI buy more computers and Bill Gates' suggestion
to me that we upgrade our research and development [blacked
out------------------------------] American industry cannot do it, and that
is decrypt real time encryption over a very minimal level of robustness.
[blacked out---------] If you gave me $3 million to buy a Cray computer,
it would take me how many years to do one message bit?
<P>
Mr. Crowell. 64 bits, 7,000 years.
<P>
Director Freeh. I don't have that time in a kidnapping case. It would kill
us.
</BLOCKQUOTE>
<P>
On March 17, 1998, Robert S. Litt, Principal Associate Deputy Attorney General,
testified to the U.S. Senate Judiciary Committee, Subcommittee on the
Constitution, Federalism, and Property. The subject of the hearing was "Privacy
in a Digital Age: Encryption and Mandatory Access". Mr. Litt's whole statement
is available at
<A HREF="http://www.computerprivacy.org/archive/03171998-4.shtml">http://www.computerprivacy.org/archive/03171998-4.shtml</A>.
The part relevant to DES cracking is:
<BLOCKQUOTE>
Some people have suggested that this is a mere resource problem for law
enforcement. They believe that law enforcement agencies should simply focus
their resources on cracking strong encryption codes, using high-speed computers
to try every possible key when we need lawful access to the plaintext of
data or communications that is evidence of a crime. But that idea is simply
unworkable, because this kind of brute force decryption takes too long to
be useful to protect the public safety. For example, decrypting one single
message that had been encrypted with a 56-bit key took 14,000 Pentium-level
computers over four months; obviously, these kinds of resources are not available
to the FBI, let alone the Jefferson City Police Department.
</BLOCKQUOTE>
<P>
<B><I>What's Wrong With Their Statements?</I></B>
<P>
Some of the testimony quoted may have been literally true; nevertheless,
it is deceptive. All of the time estimates presented by Administration officials
were based on use of general-purpose computers to do the job. But that's
fundamentally the wrong way to do it, and they know it.
<P>
A ordinary computer is ill-suited for use as a DES Cracker. In the first
place, the design of DES is such that it is inherently very slow in software,
but fast in hardware. Second, current computers do very little in parallel;
the designers don't know exactly what instructions will be executed, and
must allow for all combinations.
<P>
<HR>
<P>
<I>1-4</I>
<P>
The right way to crack DES is with special-purpose hardware. A custom-designed
chip, even with a slow clock, can easily outperform even the fastest
general-purpose computer. Besides, you can get many such chips on a single
board, rather than the one or two on a typical computer's motherboard.
<P>
There are practical limits to the key sizes which can be cracked by brute-force
searching, but since NSA deliberately limited the key size of DES to 56 bits,
back in the 1970's when it was designed, DES is crackable by brute force.
Today's technology might not be able to crack other ciphers with 64-bit or
128-bit keys--or it might. Nobody will know until they have tried, and published
the details for scientific scrutiny. Most such ciphers have very different
internal structure than DES, and it may be possible to eliminate large numbers
of possible keys by taking advantage of the structure of the cipher. Some
senior cryptographers estimated what key sizes were needed for safety in
a 1996 paper;* they suggest that to protect against brute force cracking,
today's keys should have a minimum of 75 bits, and to protect information
for twenty years, a minimum of 90 bits.
<P>
The cost of brute-force searching also overstates the cost of recovering
encrypted text in the real world. A key report on the real impact of encryption
on law enforcement<SUP>+</SUP> reveals that there are no cases in which a
lack of police access to encrypted files resulted in a suspected criminal
going free. In most cases the plaintext was recovered by other means, such
as asking the suspect for the key, or finding another copy of the information
on the disk. Even when brute force is the method of choice, keys are seldom
truly random, and can be searched in the most likely order.
<P>
<B><I>Export Controls and DES</I></B>
<P>
The U.S. Government currently restricts the ability of companies, individuals,
and researchers to export hardware or software that includes the use of DES
for confidentiality. These "export controls" have been a severe impediment
to the development of security and privacy for networked computers, cellular
phones, and other popular communications devices. The use of encryption
algorithms stronger than DES is also restricted.
<P>
In December 1996, the government formally offered exporters the ability to
incorporate DES, but nothing stronger, into their products. The catch is
that these companies would have to sign an agreement with the government,
obligating them to
<P>
___________________
<P>
<SMALL>* Minimal Key Lengths For Symmetric Ciphers To Provide Adequate Commercial
Security: A Report By An Ad Hoc Group Of Cryptographers And Computer Scientists.
Matt Blaze, Whitfield Diffie, Ronald L. Rivest, Bruce Schneier, Tsutomu
Shimomura, Eric Thompson, Michael Wiener, January 1996. Available at
<A HREF="http://www.bsa.org/policy/encryption/index.html">http://www.bsa.org/policy/encryption/index.html</A>.</SMALL>
<P>
<SMALL>+ Encryption and Evolving Technologies: Tools of Organized Crime and
Terrorism, by Dorothy E. Denning and William E. Baugh, Jr. National Strategy
Information Center, 1997. ISSN 1093-7269.</SMALL>
<P>
<HR>
<P>
<I>1-5</I>
<P>
install "key recovery" into their products within two years. Key recovery
technology provides a way for the government to decrypt messages at will,
by offering the government a copy of the key used in each message, in a way
that the product's user cannot circumvent or control. In short, the government's
offer was: collude with us to violate your customers' privacy, or we won't
let you export any kind of secure products.
<P>
At the same time, the FBI was let into the group that reviews each individual
company's application to export a cryptographic product. All reports indicate
that the FBI is making good on the threat, by objecting to the export of
all kinds of products that pose no threat at all to the national security
(having been exportable in previous years before the FBI gained a voice).
The FBI appears to think that by making itself hated and feared, it will
encourage companies to follow orders. Instead it is encouraging companies
to overturn the regulatory scheme that lets the FBI abuse the power to control
exports. Industry started a major lobbying group called Americans for Computer
Privacy
(<A HREF="http://www.computerprivacy.org/">http://www.computerprivacy.org</A>),
which is attempting to change the laws to completely decontrol nonmilitary
encryption exports.
<P>
Some dozens of companies to signed up for key recovery, though it is unclear
how many actually plan to follow through on their promise to deploy the
technology. You will not find many of these companies trumpeting key recovery
in their product advertisements. Users are wary of it since they know it
means compromised security. If customers won't buy such products, companies
know it makes no sense to develop them.
<P>
The best course for companies is probably to develop products that provide
actual security, in some jurisdiction in the world which does not restrict
their export. Some companies are doing so. The government's "compromise"
offer discourages hesitant companies from taking this step, by providing
a more moderate and conciliatory step that they can take instead. Companies
that go to the effort to build overseas cryptographic expertise all use stronger
technology than DES, as a selling point and to guard against early obsolescence.
If those companies can be convinced to stay in the US, play the government's
key-recovery game, and stick with DES, the government continues to win, and
the privacy of the public continues to lose.
<P>
The success or failure of the government's carrot-and-stick approach depends
on keeping industry and the public misled about DES's security. If DES-based
products were perceived as insecure, there would be little reason for companies
to sign away their customers' privacy birthrights in return for a mess of
DES pottage. If DES-based products are perceived as secure, but the government
actually knows that the products are insecure, then the government gets
concessions from companies,
<P>
<HR>
<P>
<I>1-6</I>
<P>
without impacting its ability to intercept communications. Keeping the public
ignorant gives the government the best of both worlds.
<P>
<B><I>Political Motivations and EFF's Response</I></B>
<P>
We speculate that government officials are deliberately misleading the public
about the strength of DES encryption:
<P>
<UL>
<LI>
To encourage the public to continue using DES, so their agencies can eavesdrop
on the public.
</UL>
<UL>
<LI>
To prevent the widespread adoption of stronger standards than DES, which
the government would have more trouble decrypting.
</UL>
<UL>
<LI>
To offer DES exportability as a bargaining-chip, which actually costs the
government little, but is perceived to be valuable.
</UL>
<UL>
<LI>
To encourage policy-makers such as Congressmen or the President to impose
drastic measures such as key recovery, in the belief that law enforcement
has a major encrypted-data problem and no practical way to crack codes.
</UL>
<P>
As advocates on cryptography policy, we found ourselves in a hard situation.
It appeared that highly credible people were either deliberately Lying to
Congress and to the public in order to advance their own harmful agendas,
or were advocating serious infringement of civil liberties based on their
own ignorance of the underlying issues. Most troubling is the possibility
that they were Lying. Perhaps these government executives merely saw themselves
as shielding valuable classified efforts from disclosure. As advocates of
good government, we do not see that classifying a program is any justification
for an official to perjure themselves when testifying about it. (Declining
to state an opinion is one thing; making untruthful statements as if they
were facts is quite another.)
<P>
The National Research Council studied encryption issues and published a very
complete 1996 report.* The most interesting conclusion of their report was
that "the debate over national cryptography policy can be carried out in
a reasonable manner on an unclassified basis". This presumes good faith on
the part of the agencies who hide behind classified curtains, though. If
it turns out that their public statements are manipulative falsehoods, an
honest and reasonable public debate must necessarily exclude them, as dishonest
and unreasonable participants.
<P>
In the alternative, if poor policy decisions are being made based on the
ignorance or incompetence of senior government officials, the role of honest
advocates should be to inform the debate.
<P>
_________________
<P>
<SMALL>* Cryptography's Role In Securing the Information Society, Kenneth
W. Dam and Herbert S. Lin, editors. National Academy Press, Washington, DC,
1996.</SMALL>
<P>
<HR>
<P>
<I>1-7</I>
<P>
In response to these concerns, EFF began a research program. Our research
results prove that DES can be cracked quickly on a low budget. This proves
that these officials were either Lying or incompetent. The book you are holding
documents the research, and allows it to be validated by other scientists.
<H3>
<I>Goals</I>
</H3>
<P>
The goal of EFF's DES Cracker research project is to determine just how cheap
or expensive it is to build a machine that cracks DES usefully.
<P>
Technically, we were also interested in exploring good designs for plaintext
recognizers. These are circuits that can notice when the result of decryption
is likely enough to be correct that specialized software--or a human--should
look at it. Little research has been published on them,* yet they are a vital
part of any efficient system for cryptanalysis.
<P>
Merely doing the research would let EFF learn the truth about the expense
of cracking DES. But only publishing the research and demonstrating the machine
would educate the public on the truth about the strength of DES. Press releases
and even technical papers would not suffice; the appearance of schematics
for a million-dollar DES Cracker in Michael Wiener's excellent 1993 paper
should have been enough. But people still deploy DES, and Congressmen blindly
accept the assurances of high officials about its strength.
<P>
There are many people who will not believe a truth until they can see it
with their own eyes. Showing them a physical machine that can crack DES in
a few days is the only way to convince some people that they really cannot
trust their security to DES.
<P>
Another set of people might not believe our claims unless several other teams
have reproduced them. (This is a basic part of the scientific method.) And
many people will naturally be interested in how such a box works, and how
it was built for only about $200,000. This book was written for such people.
It contains the complete specifications and design documents for the DES
Cracker, as well as circuit diagrams for its boards, and complete listings
of its software and its gate array design. The full publication of our design
should enable other teams to rapidly reproduce, validate, and improve on
our design.
<P>
_________________
<P>
<SMALL>* But see: David A. Wagner and Steven M. Bellovin, "A Programmable
Plaintext Recognizer," 1994. Available at
<A HREF="http://www.research.att.com/smb/papers/recog.ps">http://www.research.att.com/smb/papers/recog.ps</A>
or
<A HREF="http://www.research.att.com/smb/papers/recog.pdf">recog.pdf</A>.</SMALL>
<P>
<HR>
<P>
<I>1-8</I>
<H3>
<I>History of DES Cracking</I>
</H3>
<P>
DES Crackers have been mentioned in the scientific and popular literature
since the 1970's. Whitfield Diffie's Foreword describes several of them.
The most recent detailed description was in a paper by Michael Wiener of
Bell Northern Research in 1993. Wiener's paper included a detailed hardware
design of a DES Cracker built with custom chips. The chips were to be built
into boards, and the boards into mechanical "frames" like those of telephone
central office switches. A completed design would have cost about a million
dollars and would determine a DES key from known plaintext and known ciphertext
in an average of 3-1/2 hours (7 hours in the worst case).
<P>
Mr. Wiener updated his conclusions in 1998, adjusting for five years of
technological change. His update paper is included in this book, thanks to
the courtesy of RSA Data Security, which originally published his update.
<P>
Ian Goldberg and David Wagner of the University of California at Berkeley
took a different approach. Their design used a "field programmable gate array"
(FPGA), which is a chip that can be reprogrammed after manufacturing into
a variety of different circuits.
<P>
FPGA chips are slower than the custom chips used in the Wiener design, but
can be bought quickly in small quantities, without a large initial investment
in design. Rather than spend a big chunk of a million dollars to design a
big machine, these researchers bought one or two general purpose chips and
programmed them to be a slow DES Cracker. This let them quickly measure how
many slow chips they would need to pile up to make a practical DES Cracker.
Their paper is also included in this book.
<H3>
<I>EFF's DES Cracker Project</I>
</H3>
<P>
The Electronic Frontier Foundation began its investigation into DES Cracking
in 1997. The original plan was to see if a DES Cracker could be built out
of a machine containing a large number of FPGA's.
<P>
Large machines built out of FPGAs exist in the commercial market for use
in simulating large new chip designs before the chip is built. A collection
of thousands of relatively incapable FPGA chips can be put together to simulate
one very capable custom chip, although at 1/10th or 1/100th of the speed
that the eventual custom chip would run at. This capability is used by chip
designers to work the "bugs" out of their chip before committing to the expensive
and time-consuming step of fabricating physical chips from their design.
<P>
EFF never got access to such a chip simulator. Instead, our investigations
led us to Paul Kocher of Cryptography Research. Paul had previously worked
with a team
<P>
<HR>
<P>
<I>1-9</I>
<P>
of hardware designers who knew how to build custom gate array chips cheaply,
in batches of a few thousand chips at a time.
<P>
Paul and EFF met with the chip designers at Advanced Wireless Technologies,
and determined that a workable DES Cracker could be built on a budget of
about $200,000. The resulting machine would take less than a week, on average,
to determine the key from a single 8-byte sample of known plaintext and
ciphertext. Moreover, it would determine the key from a 16-byte sample of
ciphertext in almost the same amount of time, if the statistical characteristics
of the plaintext were known or guessable. For example, if the plaintext was
known to be an electronic mail message, it could find all keys that produce
plaintext containing nothing but letters, numbers, and punctuation. This
makes the machine much more usable for solving real-world decryption problems.
<P>
There is nothing revolutionary in our DES Cracker. It uses ordinary ideas
about how to crack DES that have been floating around in the cryptographic
research community for many years. The only difference is that we actually
built it, instead of just writing papers about it. Very similar machines
could have been built last year, or the year before, or five or ten years
ago; they would have just been slower or more expensive.
<H3>
<I>Architecture</I>
</H3>
<P>
The design of the EFF DES Cracker is simple in concept. It consists of an
ordinary personal computer connected with a large array of custom chips.
Software in the personal computer instructs the custom chips to begin searching,
and interacts with the user. The chips run without further help from the
software until they find a potentially interesting key, or need to be directed
to search a new part of the key space. The software periodically polls the
chips to find any potentially interesting keys that they have turned up.
<P>
The hardware's job isn't to find the answer. but rather to eliminate most
of the answers that are incorrect. Software is then fast enough to search
the remaining potentially-correct keys, winnowing the false positives" from
the real answer. The strength of the machine is that it replicates a simple
but useful search circuit thousands of times, allowing the software to find
the answer by searching only a tiny fraction of the key space.
<P>
As long as there is a small bit of software to coordinate the effort, the
problem of searching for a DES key is "highly parallelizable". This means
the problem can be usefully solved by many machines working in parallel,
simultaneously. For example, a single DES-Cracker chip could find a key by
searching for many years. A thousand DES-Cracker chips can solve the same
problem in one thousandth of the time. A million DES-Cracker chips could
theoretically solve the same problem in
<P>
<HR>
<P>
<I>1-10</I>
<P>
about a millionth of the time, though the overhead of starting each chip
would become visible in the time required. The actual machine we built contains
1536 chips.
<P>
When conducting a brute-force search, the obvious thing to do is to try every
possible key, but there are some subtleties. You can try the keys in any
order. If you think the key isn't randomly selected, start with likely ones.
When you finally find the right key, you can stop; you don't have to try
all the rest of the keys. You might find it in the first million tries; you
might find it in the last million tries. On average, you find it halfway
through (after trying half the keys). As a result, the timings for brute-force
searches are generally given as the average time to find a key. The maximum
time is double the average time.
<P>
<B><I>Search units </I></B>
<P>
The search unit is the heart of the EFF DES Cracker; it contains thousands
of them.
<P>
A search unit is a small piece of hardware that takes a key and two 64-bit
blocks of ciphertext. It decrypts a block of ciphertext with the key, and
checks to see if the resulting block of plaintext is "interesting". If not,
it adds 1 to the key and repeats, searching its way through the key space.
<P>
If the first decryption produces an "interesting" result, the same key is
used to decrypt the second block of ciphertext. If both are interesting,
the search unit stops and tells the software that it has found an interesting
key. If the second block's decryption is uninteresting, the search unit adds
one to the key and goes on searching the key space.
<P>
When a search unit stops after finding an interesting result, software on
the host computer must examine the result, and determine whether it's the
real answer, or just a "false positive". A false positive is a plaintext
that looked interesting to the hardware, but which actually isn't a solution
to the problem. The hardware is designed to produce some proportion of false
positives along with the real solution. (The job of the hardware isn't to
find the answer, but to eliminate the vast majority of the non-answers.)
As long as the false positives don't occur so rapidly that they overwhelm
the software s ability to check and reject them, they don't hurt, and they
simplify the hardware and allow it to be more general-purpose. For the kinds
of problems that we're trying to solve, the hardware is designed to waste
less than 1% of the search time on false positives.
<P>
<HR>
<P>
<I>1-11</I>
<P>
<B><I>Recognizing interesting plaintext</I></B>
<P>
What defines an interesting result? If we already know the plaintext, and
are just looking for the key, an interesting result would be if the plaintext
from this key matches our known block of plaintext. If we don't know the
plaintext, perhaps the guess that it's all composed of letters, digits, and
punctuation defines "interesting". The test has to be simple yet flexible.
We ended up with one that's simple for the hardware, but a bit more complicated
for the software.
<P>
Each result contains eight 8-bit bytes. First, the search unit looks at each
byte of the result. Such a byte can have any one of 256 values. The search
unit is set up with a table that defines which of these 256 byte values are
"interesting" and which are uninteresting. For example, if the plaintext
is known to be all numeric, the software sets up the table so that the ten
digits (O to 9) are interesting, and all other potential values are
uninteresting.
<P>
The result of decrypting with the wrong key will look pretty close to random.
So the chance of having a single byte look "interesting" will be based on
what fraction of the 256 values are defined to be "interesting". If, say,
69 characters are interesting (A-Z, a-z, 0-9, space, and a few punctuation
characters), then the chance of a random byte appearing to be interesting
is 69/256 or about 1/4. These don't look like very good odds; the chip would
be stopping on one out of every four keys, to tell the software about
"interesting" but wrong keys.
<P>
But the "interest" test is repeated on each byte in the result. If the chance
of having a wrong key's byte appear interesting is 1/4, then the chance of
two bytes appearing interesting is 1/4 of 1/4, or 1/16th. For three bytes,
1/4th of 1/4th of 1/4th, or 1/64th. By the time the chip examines all 8 bytes
of a result, it only makes a mistake on 1/65536th of the keys
(l/4<SUP>8</SUP> keys).
<P>
That seems like a pretty small number, but when you're searching through
72,057,594,037,927,936 keys (2<SUP>56</SUP> keys, or 72 quadrillion keys),
you need all the help you can get. Even having the software examine 1/65536th
of the possible keys would require looking at 1,099,511,627,776 keys
(2<SUP>40</SUP> or about a trillion keys). So the chip provides a bit more
help.
<P>
This help comes from that second block of ciphertext. If every byte of a
result looks interesting when the first block of ciphertext is decrypted,
the chip goes back around and decrypts the second block of ciphertext with
the same key. This divides the "error rate" by another factor of 65536, leaving
the software with only 16,777,216 (2<SUP>24</SUP> or about sixteen million)
keys to look at. Software on modern computers is capable of handling this
in a reasonable amount of time.
<P>
(If we only know one block of ciphertext, we just give the chip two copies
of the same ciphertext. It will test both copies, and eventually tell us
that the block is
<P>
<HR>
<P>
<I>1-12</I>
<P>
interesting. The amount of time it spends checking this "second block" is
always a tiny fraction of the total search time.)
<P>
In the plaintext recognizer there are also 8 bits that lets us specify which
bytes of a plaintext are interesting to examine. For example, if we know
or suspect the contents of the first six bytes of a plaintext value, but
don't know anything about the last two bytes, we can search for keys which
match in just those six bytes.
<P>
<I><B>Known plaintext</B></I>
<P>
The chips will have many fewer "false positives" if the plaintext of the
message is known, instead of just knowing its general characteristics. In
that case, only a small number of byte values will be "interesting". If the
plaintext has no repeated byte values, only eight byte values will be
interesting, instead of 69 as above.
<P>
For example, if the plaintext block is "hello th", then only the six byte
values "h", "e", "l", "o", space, and "t" are interesting. If a plaintext
contains only these bytes, it is interesting. We'll get some "false positives"
since many plaintexts like "tholo tt" would appear "interesting" even though
they don't match exactly.
<P>
Using this definition of "interesting", a byte resulting from a wrong key
will look interesting only about 8/256ths of the time, or 1/32nd of the time.
All eight bytes resulting from a wrong key will look interesting only 1/32nd
to the eighth power (1/32nd of 1/32nd of 1/32nd of 1/32nd of 1/32nd of 1/32nd
of 1/32nd of 1/32nd) of the time, or 1/1,099,511,627,776th of the time
(1/2<SUP>40</SUP> of the time). In other words, a search unit can try an
average of a trillion keys before reporting that a wrong key looks interesting.
This lets it search for a long time without slowing down or bothering the
software.
<P>
<B><I>Speed</I></B>
<P>
Once you get it going, a search unit can do one decryption in 16 clock cycles.
The chips we have built can run with a clock of 40 Mhz (40 million cycles
per second). Dividing 16 into 40 million shows that each search unit can
try about 2.5 million keys per second.
<P>
In building the search units, we discovered that we could make them run faster
if we used simpler circuitry for adding 1 to a key. Rather than being able
to count from a key of O all the way up to a key of all ones, we limited
the adder so that it can only count the bottom 32 bits of the key. The top
24 bits always remain the same. At a rate of 2.5 million keys per second,
it takes a search unit 1717 seconds (about half an hour) to search all the
possible keys that have the same top 24 bits. At the end of half an hour,
the software has to stop the chip, reload it with a new value in the top
24 bits, and start it going again.
<P>
<HR>
<P>
<I>1-13</I>
<P>
<B><I>Feedback Modes</I></B>
<P>
The chip can also decrypt ciphertext that was encrypted in "Cipher Block
Chaining" mode. In this mode, the ciphertext of each block is exclusive-OR'd
into the plaintext of the next block before it is encrypted. (An "initialization
vector" is exclusive-OR'd into the first block of plaintext.) The search
unit knows how to exclusive-OR out an Initialization Vector (IV) after decrypting
the first cyphertext, and to exclusive-OR out the first cyphertext after
decrypting the second one. The software specifies the IV at the same time
it provides the cyphertext values.
<P>
<B><I>Blaze Challenge</I></B>
<P>
In June, 1997 Matt Blaze, a cryptography researcher at AT&T, proposed
a different sort of cryptographic challenge. He wanted a challenge that not
even the proponent knew how to solve, without either doing a massive search
of the key-space, or somehow cryptanalyzing the structure of DES.
<P>
His challenge is merely to find a key such that a ciphertext block of the
form XXXXXXXX decrypts to a plaintext block of the form YYYYYYYY, where X
and Y are any fixed 8-bit value that is repeated across each of the eight
bytes of the block.
<P>
We added a small amount of hardware to the search units to help with solving
this challenge. There is an option to exclusive-OR the right half of the
plaintext into the left half, before looking to see if the plaintext is
"interesting". For plaintexts of the form YYYYYYYY, this will result in a
left half of all zeros. We can then set up the plaintext recognizer so it
only looks at the left half, and only thinks zeroes are interesting. This
will produce a large number of false positives (any plaintext where the left
and right halves are equal, like ABCDABCD), but software can screen them
out with only about a 1% performance loss.
<P>
<B><I>Structure Of The Machine</I></B>
<P>
Now that you know how a single search unit works. Let's put them together
into the whole machine.
<P>
Each search unit fits inside a custom chip. In fact, 24 search units fit
inside a single chip. All the search units inside a chip share the same
ciphertext blocks. initialization vector, and the same plaintext-recognizer
table of "interesting" result values. Each search unit has its own key, and
each can be stopped and started independently.
<P>
The chip provides a simple interface on its wires. There are a few signals
that say whether any of the search units are stopped, some address and data
wires so that
<P>
<HR>
<P>
<I>1-14</I>
<P>
the software can read and write to the search units, and wires for electrical
power and grounding.
<P>
Since each search unit tries 2.5 million keys per second, a chip with 24
search units will try 60 million keys per second. But there are a lot of
keys to look at. For a single chip, it would take 6,950 days (about 19 years)
to find the average key, or 38 years to search the entire key space. Since
we don't want to wait that long, we use more than one chip.
<P>
Each chip is mounted onto a large circuit board that contains 64 chips, along
with a small bit of interface circuitry. The board blinks a light whenever
the software is talking to that board. 64 other lights show when some search
unit in each chip has stopped. In normal operation the software will talk
to the board every few seconds, to check up on the chips. The chips should
only stop every once in a while, and should be quickly restarted by the software.
<P>
The boards are designed to the mechanical specifications of "9U" VMEbus boards
(about 15" by 15"). VMEbus is an industrial standard for computer boards,
which was popular in the 1980s. We used the VMEbus form factor because it
was easy to buy equipment that such boards plug into; we don't actually use
the VMEbus electrical specifications.
<P>
9U VMEbus boards are much larger than the average interface card that plugs
into a generic PC, so a lot more chips can be put onto them. Also, 9U VMEbus
boards are designed to supply a lot of power, and our DES Cracker chips need
it.
<P>
Since each chip searches 60 million keys per second, a board containing 64
chips will search 3.8 billion keys per second. Searching half the key space
would take the board about 109 days. Since we don't want to wait that long
either, we use more than one board.
<P>
The boards are mounted into chassis, also called "card cages". In the current
design, these chassis are recycled Sun workstation packages from about 1990.
Sun Microsystems built a large number of system.s that used the large 9U
VMEbus boards, and provide excellent power and cooling for the boards. The
Sun-4/470 chassis provides twelve slots for VMEbus boards, and can easily
be modified to handle our requirements. Subsequent models may use other physical
packaging.
<P>
Each chassis has a connector for a pair of "ribbon cables to connect it to
the next chassis and to the generic PC that runs the software. The last chassis
will contain a "terminator", rather than a connection to the next chassis,
to keep the signals on the ribbon cable from getting distorted when they
reach the end of the line.
<P>
Since each board searches 3.8 billion keys per second, a chassis containing
12 boards will search 46 billion keys per second. At that rate, searching
half the key space takes about 9 days. One chassis full of boards is about
25% faster than the
<P>
<HR>
<P>
<I>1-15</I>
<P>
entire worldwide network of machines that solved the RSA "DES-II" challenge
in February 1998, which was testing about 34 billion keys per second at its
peak.
<P>
Since an informal design goal for our initial DES Cracker was to crack an
average DES key in less than a week, we need more than 12 boards. To give
ourselves a comfortable margin, we are using 24 boards, which we can fit
into two chassis. They will search 92 billion keys per second, covering half
the key space in about 4.5 days. If the chips consume too much power or produce
too much heat for two chassis to handle,* we can spread the 24 boards across
three chassis.
<P>
<TABLE BORDER CELLPADDING="12">
<TR>
<TD COLSPAN="4"><P ALIGN="Center">
Table 1-1: Summary of DES Cracker performance</TD>
</TR>
<TR>
<TD><P ALIGN="Center">
Device</TD>
<TD><P ALIGN="Center">
How Many In Next Device</TD>
<TD><P ALIGN="Center">
Keys/Sec</TD>
<TD><P ALIGN="Center">
Days/avg search</TD>
</TR>
<TR>
<TD>Search Unit</TD>
<TD><P ALIGN="Center">
24</TD>
<TD><P ALIGN="Right">
2,500,000</TD>
<TD><P ALIGN="Right">
166,800</TD>
</TR>
<TR>
<TD>Chip</TD>
<TD><P ALIGN="Center">
64</TD>
<TD><P ALIGN="Right">
60,000,000</TD>
<TD><P ALIGN="Right">
6,950</TD>
</TR>
<TR>
<TD>Board</TD>
<TD><P ALIGN="Center">
12</TD>
<TD><P ALIGN="Right">
3,840,000,000</TD>
<TD><P ALIGN="Right">
109</TD>
</TR>
<TR>
<TD>Chassis</TD>
<TD><P ALIGN="Center">
2</TD>
<TD><P ALIGN="Right">
46,080,000,000</TD>
<TD><P ALIGN="Right">
9.05</TD>
</TR>
<TR>
<TD>EFF DES Cracker</TD>
<TD></TD>
<TD><P ALIGN="Right">
92,160,000,000</TD>
<TD><P ALIGN="Right">
4.524</TD>
</TR>
</TABLE>
<P>
<P>
We designed the search unit once. Then we got a speedup factor of more than
36,000 to 1 just by replicating it 24 times in each chip and making 1500
chips. This is what we meant by "highly parallelizable"
<P>
<B><I>Budget</I></B>
<P>
The whole project was budgeted at about US$210,000. Of this, $80,000 is for
the labor of designing, integrating, and testing the DES Cracker. The other
$130,000 is for materials, including chips, boards, all other components
on the boards, card cages, power supplies, cooling, and a PC.
<P>
The software for controlling the DES Cracker was written separately, as a
volunteer project. It took two or three weeks of work.
<P>
The entire project was completed within about eighteen months. Much of that
time was used for preliminary research, before deciding to use a custom chip
rather than FPGA's. The contract to build custom chips was signed in September,
1997, about eight months into the project. The team contained less than ten
people, none of whom worked full-time on the project. They include a project
manager, software designer, programmer, chip designer, board designer, hardware
technicians, and hardware managers.
<P>
_________________
<P>
<SMALL>* At publication time, we have tested individual chips but have yet
not built the full machine If the chips' power consumption or heat production
is excessive in a machine containing 1500 chips, we also have the option
to reduce the chips' clock rate from 40 MHz down to, say, 30 MHz. This would
significantly reduce the power and heat problems, at a cost of 33% more time
per search (6 days on average).</SMALL>
<P>
<HR>
<P>
<I>1-16</I>
<P>
We could have reduced the per-chip cost, or increased the chip density or
search speed, had we been willing to spend more money on design. A more complex
design could also have been flexible enough to crack other encryption algorithms.
The real point is that for a budget that any government, most companies,
and tens of thousands of individuals could afford, we built a usable DES
Cracking machine. The publication of our design will probably in itself reduce
the design cost of future machines, and the advance of semiconductor technology
also makes this cost likely to drop. In five years some teenager may well
build her own DES Cracker as a high school science fair project.
<H3>
<I>Who Else Is Cracking DES?</I>
</H3>
<P>
If a civil liberties group can build a DES Cracker for $200,000, it's pretty
likely that governments can do the same thing for under a million dollars.
(That's a joke.) Given the budget and mission of the US National Security
Agency, they must have started building DES Crackers many years ago. We would
guess that they are now on their fourth or fifth generation of such devices.
They are probably using chips that are much faster than the ones we used;
modern processor chips can run at more than 300 Mhz, eight times as fast
as our 40 Mhz chips. They probably have small "field" units that fit into
a suitcase and crack DES in well under a day; as well as massive central
units buried under Ft. Meade, that find the average DES key in seconds, or
find thousands of DES keys in parallel, examining thousands of independent
intercepted messages.
<P>
Our design would scale up to finding a DES key in about half an hour, if
you used 333,000 chips on more than 5,200 boards. The boards would probably
require about 200 parallel port cards to communicate with them; an IBM-compatible
PC could probably drive four such cards, thus requiring about 50 PC's too.
The software required would be pretty simple: the hard part would be the
logistics of physical arrangement and repair. This is about 200 times as
much hardware as the project we built. A ridiculously high upper bound on
the price of such a system would be 200 times the current project price,
or S40 million
<P>
Of course, if we were going to build a system to crack DE.S in half an hour
or less, using a third of a million chips, it would be better to go back
to the drawing board and design from scratch. We'd use more modern chip
fabrication processes; a higher-volume customer can demand this. We d spend
more on the initial design and the software, to produce a much cheaper and
simpler total system, perhaps allowing boards full of denser, faster,
lower-voltage chips to use a small onboard processor and plug directly into
an Ethernet. We'd work hard to reduce the cost of each chip, since there
would be so many of them. We'd think about how to crack multiple DES keys
simultaneously.
<P>
<HR>
<P>
<I>1-17</I>
<P>
It would be safe to assume that any large country has DES Cracking machines.
After the publication of this book wakes them up, probably more small countries
and some criminal organizations will make or buy a few DES Crackers. That
was not the intent of the book; the intent was to inform and warn the targets
of this surveillance, the builders of equipment, and the policy makers who
grapple with encryption issues.
<H3>
<I>What To Do If You Depend On DES</I>
</H3>
<P>
Don't design anything else that depends on single DES.
<P>
Take systems out of service that use permanently fixed single-DES keys, or
superencrypt the traffic at a higher level. Superencryption requires special
care, though, to avoid providing any predictable headers that can be used
to crack the outer DES encryption.
<P>
Start changing your software and/or hardware to use a stronger algorithm
than DES.
<P>
Three-key Triple-DES is an obvious choice, since it uses the same block size
and can possibly use the same hardware; it just uses three keys and runs
DES three times (encrypting each block with the first key, decrypting it
with the second, then encrypting it with the third). The strength of Triple-DES
is not known with any certainty, but it is certainly no weaker than single
DES, and is probably substantially stronger. Beware of "mixed up" variants
or modes of Triple-DES; research by Eli Biham* and David Wagner<SUP>+</SUP>
shows that they are significantly weaker than the straightforward Triple-DES,
and may be even weaker than single-DES. Use three copies of DES in Electronic
Code Book (ECB) mode as a basic primitive. You can then build a mode such
as Cipher Feedback mode using the primitive ECB 3DES.
<P>
The US Government is tardily going through a formal process to replace the
DES. This effort, called the Advanced Encryption Standard, will take several
years to decide on a final algorithm, and more years for it to be proven
out in actual use, and carefully scrutinized by public cryptanalysts for
hidden weaknesses. If you are designing products to appear five to ten years
from now, the AES might be a good source of an encryption algorithm for you.
<P>
The reason that the AES is tardy is because the NSA is believed to have blocked
previous attempts to begin the process over the last decade. In recent years
NSA
<P>
_______________
<P>
<SMALL>* "Cryptanalysis of Triple-Modes of Operation", Eli Biham, Technion
Computer Science Department Technical Report CS0885, 1996.</SMALL>
<P>
<SMALL>+"Cryptanalysis of some Recently Proposed Multiple Modes of Operation",
David Wagner, University of California at Berkeley,
<A HREF="http://www.cs.berkeley.edu/~daw/multmode-fse98.ps">http://www.cs.berkeley.edu/~daw/multmode-fse98.ps</A>.
Presented at the 1998 Fast Software Encryption workshop.</SMALL>
<P>
<HR>
<P>
<I>1-18</I>
<P>
has tried, without success, to get the technical community to use classified,
NSA-designed encryption algorithms such as Skipjack, without letting the
users subject these algorithms to public scrutiny. Only after this effort
failed did they permit the National Institute of Standards and Technology
to begin the AES standardization process.
<H3>
<I>Conclusion</I>
</H3>
<P>
The Data Encryption Standard has served the public pretty well since 1975.
But it was designed in an era when computation cost real money, when massive
computers hunkered on special raised flooring in air-conditioned inner sanctums.
In an era when you can carry a supercomputer in your backpack, and access
millions of machines across the Internet, the Data Encryption Standard is
obsolete.
<P>
The Electronic Frontier Foundation hopes that this book inspires a new level
of truth to enter the policy debates on encryption. In order to make wise
choices for our society, we must make well-informed choices. Great deference
has been paid to the perspective and experience of the National Security
Agency and Federal Bureau of Investigation in these debates. This is particularly
remarkable given the lack of any way for policy-makers or the public to check
the accuracy of many of their statements.* (The public cannot even hear many
of their statements, because they are classified as state secrets.) We hope
that the crypto policy debate can move forward to a more successful and generally
supported policy. Perhaps if these agencies will consider becoming more truthful,
or policy-makers will stop believing unverified statements from them, the
process can move more rapidly to such a conclusion.
<P>
_________________
<P>
<SMALL>* DES cracking is not the only issue on which agency credibility is
questionable. For example, the true extent of the law enforcement problem
posed by cryptography is another issue on which official dire predictions
have been made, while more careful and unbiased studies have shown little
or no impact. The validity of the agencies' opinion of the constitutionality
of their own regulations is also in doubt, having been rejected two decades
ago by the Justice Department, and declared unconstitutional in 1997 by a
Federal District Court. The prevalence of illegal wiretapping and communications
interception by government employees is also in question; see for example
the Los Angeles Times story of April 26, 1998, "Can the L.A. Criminal-Justice
System Work Without Trust?" </SMALL>
<P>
</BODY></HTML>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed