From rec.arts.sf.reviews Mon Apr 20 16:13:04 1998 Path: news.ifm.liu.se!news.lth.se!feed1.news.luth.se!luth.se!feed2.news.erols.com!erols!netnews.com!eecs-usenet-02.mit.edu!news.media.mit.edu!not-for-mail From: "Rob Slade, doting grandpa of Ryan and Trevor" Newsgroups: rec.arts.sf.reviews Subject: REVIEW: "Digital Fortress", Dan Brown Followup-To: rec.arts.sf.written Date: 17 Apr 1998 13:52:03 -0400 Organization: Vancouver Institute for Research into User Lines: 135 Approved: wex@media.mit.edu Message-ID: Reply-To: rslade@sprint.ca NNTP-Posting-Host: tinbergen.media.mit.edu X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: news.ifm.liu.se rec.arts.sf.reviews:1858 "Digital Fortress" by Dan Brown 1998, 0-312-18087-X, U$24.95/C$33.95 Review Copyright 1988 Robert M. Slade 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? 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. You can't weld ceramic and, 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? 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. 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. %A Dan Brown danbrown@digitalfortress.com %C 175 Fifth Ave., New York, NY 10010 %D 1998 %G 0-312-18087-X %I St. Martin's Press %O U$24.95/C$33.95 212-674-5151 fax 800-288-2131 www.stmartins.com %P 384 p. %T "Digital Fortress"