Correcting Digital Fortress
I've just started reading Dan Brown's Digital Fortress, and am appalled at the total abandon of basic facts. That it is just fiction really does not exonerate the author from skipping research or ignoring facts. Originally, I was pretty impressed by the details in The DaVinci Code. Digital Fortress has made me wonder if the former was just as error-ridden as its predecessor.
This post is an ongoing list of oddities as I read the amazingly confused story:
1) Pg 35 - 38: Confusion between characters and bits. A 64-character key does not equal a 64-bit key. The original ASCII character set had 7 bits per character; the extended ASCII set had 8. A 64-character key would have at least 448-bits. (I-cannot-believe-he-wrote-that-scale: 10/10)
2) Pg 36: TRANSLTR has 3 million processors? IBM's Blue Gene has 1 million processors, and IBM had to overcome the problem of processors failing routinely. I'm no computer engineer, but with the bottleneck in performance and memory, a distributed system might actually work better than TRANSLTR's "iceberg" architecture. (I-cannot-believe-he-wrote-that-scale: 2/10)
3) Pg 43: 10,000-bit keys. Most encryption standards employ 128 or 256 bit keys. Since TRANSLTR is supposed to be top secret, who in their right minds will use 10,000 bit keys? (I-cannot-believe-he-wrote-that-scale: 4/10)
4) Pg 43: Segmented keys, illegal looping, cellular automata. All are common terms but their application to encryption is unknown to me. Nonsensical jargon? (I-cannot-believe-he-wrote-that-scale: 2/10)
5) Pg 43: Finetuning the TRANSLTR. TRANSLTR is a brute-force-type codebreaker. Iterating through the finite keyspace of a key hardly requires any finetuning in terms of programming. (I-cannot-believe-he-wrote-that-scale: 6/10)
6) Pg 35/ 43: TRANSLTR takes 10 mins to break a 64-bit key, and 1 hour to break a 10,000 bit key. First of all, assuming that the time taken to break a 64-bit key increases linearly when it comes to the 10,000 bit keys, the operation should finish in over 1500 minutes, or or approx. 26 hours. It therefore seems TRANSLTR requires warm-up time. Furthermore, the increase in time needed is not linear but exponential. The actual time taken should be so much more significantly higher than 1 hour. (I-cannot-believe-he-wrote-that-scale: 10/10)
7) Pg 46: Bergofsky's Principle- no key is unbreakable. Doesn't exist simply because there is no "mathematical guarantee" that all encryption can be broken. The one time pad has been mathematically proven to be unbreakable, as long as several criteria are fulfilled (Google 'Shannon, unbreakable' if you're so inclined) (I-cannot-believe-he-wrote-that-scale: 10/10)
8) Pg 47: If TRANSLTR cannot understand the cleartext when it has found the key, it continues iterating. This is the dumbest thing I've read so far. Accordingly, if a terrorist were to send encrypted gibberish, TRANSLTR will indefinitely stall because the translated cleartext is non-recognizable and it thinks it hasn't found the key. The terrorists will have a field day. Furthermore, this fatal weakness also ensures that TRANSLTR is bound to fail as long as more than 1 key is used. Since breaking the first key still results in a non-recognizable cipher, TRANSLTR will never know it has found the first key. This is known as multi-layered encryption, and it is not uncommon. (I-cannot-believe-he-wrote-that-scale: 11/10)
9) Pg 47: Rotating cleartext. Not only does rotating cleartext not exist, but by the given definition of "shifting decrypted cleartext over a time variant" to achieve "perpetual mutation", it will result in the receiver never being able to read the entire cleartext since the decryption process never ends. Encryption is pointless if there is no cleartext to read. (I-cannot-believe-he-wrote-that-scale: 8/10)
10) Pg 49: Bragging about making a brute force resistant algorithm. I wouldn't do that if I were him, since all it takes is to google "unbreakable encryption" to find the one time pad/ Vernam cipher. Which self-respecting programmer doesn't google? (I-cannot-believe-he-wrote-that-scale: 6/10)
11) Pg 50: Biggleman's Safe. Never heard of it. (I-cannot-believe-he-wrote-that-scale: 1/10)
12) Pg 68: Viruses in TRANSLTR. Ciphers are usually plaintext. Getting hit by virus infections when no one knows the existence of TRANSLTR would be really stupid. You'd think with 3 million processors, the programmers could have bought a better virus scanner that's more reliable than the dubious sounding Gauntlet. (I-cannot-believe-he-wrote-that-scale: 3/10)
Filed under: Books, Rant
This post is an ongoing list of oddities as I read the amazingly confused story:
1) Pg 35 - 38: Confusion between characters and bits. A 64-character key does not equal a 64-bit key. The original ASCII character set had 7 bits per character; the extended ASCII set had 8. A 64-character key would have at least 448-bits. (I-cannot-believe-he-wrote-that-scale: 10/10)
2) Pg 36: TRANSLTR has 3 million processors? IBM's Blue Gene has 1 million processors, and IBM had to overcome the problem of processors failing routinely. I'm no computer engineer, but with the bottleneck in performance and memory, a distributed system might actually work better than TRANSLTR's "iceberg" architecture. (I-cannot-believe-he-wrote-that-scale: 2/10)
3) Pg 43: 10,000-bit keys. Most encryption standards employ 128 or 256 bit keys. Since TRANSLTR is supposed to be top secret, who in their right minds will use 10,000 bit keys? (I-cannot-believe-he-wrote-that-scale: 4/10)
4) Pg 43: Segmented keys, illegal looping, cellular automata. All are common terms but their application to encryption is unknown to me. Nonsensical jargon? (I-cannot-believe-he-wrote-that-scale: 2/10)
5) Pg 43: Finetuning the TRANSLTR. TRANSLTR is a brute-force-type codebreaker. Iterating through the finite keyspace of a key hardly requires any finetuning in terms of programming. (I-cannot-believe-he-wrote-that-scale: 6/10)
6) Pg 35/ 43: TRANSLTR takes 10 mins to break a 64-bit key, and 1 hour to break a 10,000 bit key. First of all, assuming that the time taken to break a 64-bit key increases linearly when it comes to the 10,000 bit keys, the operation should finish in over 1500 minutes, or or approx. 26 hours. It therefore seems TRANSLTR requires warm-up time. Furthermore, the increase in time needed is not linear but exponential. The actual time taken should be so much more significantly higher than 1 hour. (I-cannot-believe-he-wrote-that-scale: 10/10)
7) Pg 46: Bergofsky's Principle- no key is unbreakable. Doesn't exist simply because there is no "mathematical guarantee" that all encryption can be broken. The one time pad has been mathematically proven to be unbreakable, as long as several criteria are fulfilled (Google 'Shannon, unbreakable' if you're so inclined) (I-cannot-believe-he-wrote-that-scale: 10/10)
8) Pg 47: If TRANSLTR cannot understand the cleartext when it has found the key, it continues iterating. This is the dumbest thing I've read so far. Accordingly, if a terrorist were to send encrypted gibberish, TRANSLTR will indefinitely stall because the translated cleartext is non-recognizable and it thinks it hasn't found the key. The terrorists will have a field day. Furthermore, this fatal weakness also ensures that TRANSLTR is bound to fail as long as more than 1 key is used. Since breaking the first key still results in a non-recognizable cipher, TRANSLTR will never know it has found the first key. This is known as multi-layered encryption, and it is not uncommon. (I-cannot-believe-he-wrote-that-scale: 11/10)
9) Pg 47: Rotating cleartext. Not only does rotating cleartext not exist, but by the given definition of "shifting decrypted cleartext over a time variant" to achieve "perpetual mutation", it will result in the receiver never being able to read the entire cleartext since the decryption process never ends. Encryption is pointless if there is no cleartext to read. (I-cannot-believe-he-wrote-that-scale: 8/10)
10) Pg 49: Bragging about making a brute force resistant algorithm. I wouldn't do that if I were him, since all it takes is to google "unbreakable encryption" to find the one time pad/ Vernam cipher. Which self-respecting programmer doesn't google? (I-cannot-believe-he-wrote-that-scale: 6/10)
11) Pg 50: Biggleman's Safe. Never heard of it. (I-cannot-believe-he-wrote-that-scale: 1/10)
12) Pg 68: Viruses in TRANSLTR. Ciphers are usually plaintext. Getting hit by virus infections when no one knows the existence of TRANSLTR would be really stupid. You'd think with 3 million processors, the programmers could have bought a better virus scanner that's more reliable than the dubious sounding Gauntlet. (I-cannot-believe-he-wrote-that-scale: 3/10)
Filed under: Books, Rant








Technorati Profile


9 Comments
End of story.
Appendix: Dan Brown is a RICH fuckwit.
~dawna~
Hannah: it's like how kpmg audited nkf's finances. i wouldn't know how nkf does it either :) just find it appalling he can squeeze so much wrong stuff in 50 pages.
dawna: i don't think i can finish this book. i think if you've read one of his books, you've pretty much read them all.
pangy: he thanked two anonymous NSA cyptographers who helped him. now i know why they wanted to be anonymous.
[url=http://jnoffhfj.com/anoy/ilmn.html]My homepage[/url] | [url=http://akmiwlop.com/vwan/ghui.html]Cool site[/url]
My homepage | Please visit
http://jnoffhfj.com/anoy/ilmn.html | http://mxxaxmvz.com/kyfq/dbcs.html
Post a Comment
<< Home