Book details of 'Digital Fortress'

Title	Digital Fortress
Author(s)	Dan Brown
ISBN	031218087X
Language	English
Published	February 1998
Publisher	St. Martin's Press

---

Back to shelf Computer security
Back to shelf Privacy
Amazon.com info for Digital Fortress

Score:

virtualbookcase.com score: 5.0   Vote for this book

The Virtual Bookcase Reviews of 'Digital Fortress':

Reviewer Koos van den Hout wrote:
In this book Dan Brown writes about cryptography and privacy, and the role of the NSA. It starts by letting the reader feel for the NSA and their work to protect the US, but in the long run the good-guy / bad-guy roles are reversed as (another) attempt is made by the NSA to influence cryptography, only to be thwarted in the attempt. This book interests me as both privacy and cryptography are subjects that interest me. I read it in a new edition that came out after the popularity of the Da Vinci Code but the book is clearly written earlier. Before 11 september 2001. Before the euro. The author tries to sound informed about the developments in cryptography for the common user but sometimes misses the boat completely. Besides technicalities, this is an interesting book to read. It has a human story, even a love story. That story has a happy ending. It is a gripping read, I finished it in two days.
Reviewer amazon.com wrote:
In most thrillers, "hardware" consists of big guns, airplanes, military vehicles, and weapons that make things explode. Dan Brown has written a thriller for those of us who like our hardware with disc drives and who rate our heroes by big brainpower rather than big firepower. It's an Internet user's spy novel where the good guys and bad guys struggle over secrets somewhat more intellectual than just where the secret formula is hidden--they have to gain understanding of what the secret formula actually is. In this case, the secret formula is a new means of encryption, capable of changing the balance of international power. Part of the fun is that the book takes the reader along into an understanding of encryption technologies. You'll find yourself better understanding the political battles over such real-life technologies as the Clipper Chip and PGP (Pretty Good Privacy) software even though the book looks at the issues through the eyes of fiction. Although there's enough globehopping in this book for James Bond, the real battleground is cyberspace, because that's where the "bomb" (or rather, the new encryption algorithm) will explode. Yes, there are a few flaws in the plot if you look too closely, but the cleverness and the sheer fun of it all more than make up for them. There are enough twists and turns to keep you guessing and a lot of high, gee-whiz-level information about encryption, code breaking, and the role they play in international politics. Set aside the whole afternoon and evening for it and have finger food on hand for supper--you may want to read this one straight through.
Reviewer Rob Slade wrote:
Dear Dan, Thanks for getting St. Martin's to send along the book. I enjoyed it a lot. Your characters are great, and the device of having the physical "street" action run in parallel with the cerebrations going on in Crypto was quite effective. It lost a little when the action in Crypto got physical, and at times the street activity skated a bit close to farce, but that's a fine line with thrillers anyway. You have a fine touch with dialogue, and the misunderstandings caused by specific messages was particularly realistic. (Although, if I may say, the people who staff your command center are a bit thick: I got it sixteen pages before they did.) However, I suspect that whoever suggested the review project to you didn't tell you the whole story. The books reviewed here are critiqued on the basis of technology, including the fiction. And on that score, well, there are a few things you might want to reconsider on your next effort. I will say that you have included a good presentation of ciphering, although you sometimes seem to get codes and ciphers confused. ("Without wax" is a code, and therefore not subject to decryption.) You have also stressed the importance of key lengths, which, along with the algorithm used, is critical to determining the strength of encryption. Cryptographic key length is usually expressed in bits, but you often refer to keys with different lengths of characters. A character is usually measured as a byte, or eight bits. (Incidentally, ASCII characters were original defined as seven bits, so there are only 128, not 256.) Let me point out, though, that *adding* a single bit (not character) to a key length is generally considered to double the key space, essentially doubling the time necessary to crack a given key. Let's start with arithmetic. If your TRANSLTR superdecrypter is able to crack a 64 *character* key in ten minutes, a 65 character key will take about a day. A 66 character key will need about four months. However, in the book, a 10,000 bit key, which is equivalent to 1,250 bytes and roughly twenty *times* as long as your 64 byte key, only takes an hour. A key length a hundred times as long as the 10,000 bits takes only three hours. Sticking with calculations, I note that your command center, dominated by a 30' by 40' video wall, required the excavation of 250 metric tons of earth. If so, the room is less than eight feet from front to back, even if it was earth that was excavated and not rock, as one might expect at 214 feet down. In the same vein, TRANSLTR is housed in something no more than twenty three feet across and eight stories deep. But if we assume that the three million processors in it are no more advanced than, say, Pentiums, then the processors themselves are going to occupy a solid block of space ten feet thick and five stories high, even if the "spray-seal" doesn't add too much bulk. (I assume that by "VSLI" you mean VLSI, very large scale integration?) This disregards the space needed for memory, support chips, the boards themselves, cabling, interfaces, catwalks, and the oft-mentioned generators and cooling system, never mind enough air to support a fire. (While we are on the subject, we might as well mention chemistry: fire consumes oxygen, it doesn't usually release it.) A short detour via linguistics. Japanese ideographs are, as you say, based on Chinese ideographs. The similarity is not confined to the form of the symbols, though: enough of the meaning should come through in either language. (Of course, if you have the actual symbols, it should be clear which language is being used. The biggest problem would be in determining representation for the symbols. Unicode, anyone?) And, finally, to computers. Just to get these points out of the way, Grace Murray Hopper's moth was found in the Mark II, not the Mark I, and was not the first use of the term "bug" (although it may have been the origin of the use of "debugging"). PGP (Pretty Good Privacy) is not an algorithm, although it is one of the most widely used implementations. First of all, you can't weld ceramic, and secondly, if you do weld the computer shut, you have rendered it instantly obsolete. Even Deep Blue got rebuilt between matches. Next, it makes no sense to say that the computer uses quantum states "rather than" binary for storage. Binary is, in a basic sense, a quantum state, and quantum physics could be used to build devices that store binary information. (All information can be stored in a binary system.) Also, I know about silicon, CMOS (complementary metal oxide semiconductor), and gallium- arsenide but ... titanium-strontium? And, OK, I know titanium burns, but you have to get it pretty darn hot in order to do so. Yes, some languages are similar enough that it makes it easy for someone who has learned one to learn the other. However, it doesn't mean that you automatically know how to use a third. When programs are created, though, they are generally compiled into machine language. (Certainly programs in Pascal and C are.) That means it doesn't matter what languages you know: typing source commands into the keyboard isn't going to affect the running program. Some scripting languages use the source files, but Pascal and C don't qualify. But the difference between source and object code raises another point: the net would not automatically adopt an encryption standard without having the source code and a description of the algorithm to examine. The source code for PGP is available, and many people compile their program directly from the source, not trusting an already compiled version. Therefore, a "trap-doored" Digital Fortress would be detected almost immediately. (The publication of the Skipjack algorithm did result in the detection of a bug: ironically the bug would have let the public use non-escrowed keys with it, rendering the government's attempt to read messages much more difficult.) Your email tracer doesn't make any sense: if you can't find the guy, how can you find his site? Also, even if you could link back to him somehow, as I get everlastingly tired of repeating, you can't send programs in text messages (at least, not without it being blindingly obvious). More importantly, it doesn't matter how powerful your computer is, you can't decrypt a message with a key if you don't know the algorithm. Key length is important, but so is the algorithm used. A 56 bit (that's seven bytes, by the way) key can be very strong in one algorithm, and relatively weak in another. Also, the importance of public-key encryption does not lie simply in the strength of the algorithm. It is the "public" aspect that is so important. Correspondents who have not met can be completely sure of the authentication of the other without ever knowing identities. A fraudulent "North Dakota" would not be a problem to someone who really knew about encryption. Finally, there is my field, viruses. It makes no sense to create a virus for a one-of-a-kind computer, since viruses, as you eventually do point out, are meant to reproduce. Most of what you say about viruses makes no sense, including "mutation strings" and "rotating cleartext." Viruses do not infect data, or, if they do, they just corrupt it, rather than continuing to spread. I suppose you can "cross-breed [viruses] into oblivion," but it's easier to delete than overwrite them. And finally, what you have isn't a virus, and, no, it isn't a worm either. (Worms reproduce, too.) What you have is the classic, common or garden trojan horse. The bane of greedy net surfers everywhere. copyright Robert M. Slade, 1998
Add my review for Digital Fortress