REVIEW: "Digital Fortress", Dan Brown

[Rob Slade, doting grandpa of Ryan and Trevor]

"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 danb...@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"