JackBauer
stranger
Reged: 04/08/04
Posts: 1
|
|
I found this book pretty enjoyable, but as many of you have already pointed out upon closer inspection this book reveals many plot holes. I find the most troubling one to be this:
The idea of rotating cleartext appears to me to have absolutely no usefulness on a practical level. Maybe I'm missing something, but if the text shifts even after inputting the right key, then how the heck do you EVER read the message? I don't see how Digital Fortress could even work based on the nonsense idea of a rotating cleartext(Yes, I know DF turned out to be fake, but even the concept of rotating cleartext makes no sense)
Secondly, after Strathmore explains his plan to Susan, she has a revelation
"If Digital Fortress is going to be the NSA's new baby, Strathmore wants to make sure it's unbreakable!"
I fail to see the importance in this, other than academic interest. He KILLED Chartrukian just to see if DF really was unbreakable? Everyone was going to end up switching to it anyway, who cares if it really is unbreakable or not?
Thirdly, how the heck do Hulohot know the names of his countless victims if he was deaf?!
|
Sephia
Supreme Goddess
Reged: 11/28/03
Posts: 876
Loc: MA, USA
|
|
I can answer the third question: he read them.
--------------------
"Your life is yours alone, rise up and live it" ~Terry Goodkind
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
Hmmm, I see what you're saying. Perhaps the cleartext is rotated on it's own algorithm, so TRANSLTR looks for the algorithm for the key by searching for comprehendable strings in the cleartext, but since it's rotaing, it will never find it. But the key code is a string that is actually two codes in one. The first half contaning the instructions for unlocking the cleartext and the other half for unlocking the whole thing. Just an idea.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Actually, "rotating cleartext" is just an alternate description of "layered encryption"--the concept of encrypting something multiple times (preferably using different schemes).
The point is that brute-force cryptanalysis needs some mechanism for determining that it has found the correct key, and the only way to do that is to examine the decrypted result and check it for recognizable word patterns in the language(s) you expect the plaintext to be written in. Oversimplifying things somewhat, you generate a test key, try decrypting the ciphertext, and you end up with something that you can test against dictionaries. If what you find contains recognizable words, you've probably found the correct key.
With layered encryption, though, the plaintext gets encrypted at least twice--the first-generation ciphertext is encrypted again with a different key and/or algorithm, to produce a second-generation ciphertext. A brute-force decryption expecting a single key will never end up with recognizable words to dictionary-match, since even when it tests the correct second-generation key it will end up with apparent gibberish. The sender and recipient in this case need to know both keys, obviously, and the order in which to apply them.
Now imagine that you changed keys many times, rather than just twice--perhaps even once for every character in the plaintext. You'd have as many layers of encryption in the ciphertext as you had characters in the original document. Obviously it would be cumbersome to keep track of a large number of keys (and the sequence to use them in), which is why most layered encryption schemes don't use more than a handful of layers, but in principle you could do it as many times as you like.
More importantly, though, the idea of such a code being "unbreakable" is the point at issue. No such code is unbreakable in an *absolute* sense--each layer of encryption merely makes the brute-force attack take exponentially longer to work out. Add enough layers, though, and this makes the code unbreakable in *practical* terms, even for machines like TRANSLTR.
|
AAnnAArchy
Gifted Procrastinator
Reged: 10/20/03
Posts: 643
Loc: Las Vegas
|
|
Wow, I need to find a graemlin with a plane whooshing over my head. 
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
But arras, that's not what it was talking about. It was not multiple layers, it was one layer, but with the cleartext shifting beneath it. If you think aobut it, it's practically impossible to do. There is no way for the cleartext to become clear. (disregaurd what I said earlier). ow do you expect to shift the text underneath at all in the first place? Say we can do it, it would still have to be based on an algorithem fi you want to get it back, and all algorithems need some sort of key. Brwon says something about useing mutation strings, there is no such thing. rotating cleartext is impossible. No matter what, you would still be able to brute force it.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Oh I agree that the concept as Brown describes it is unworkable. What I was trying to point out is that he was "close" to getting it right. In his consulations with cryptographers I suspect he tried a bit too hard to put things into layman's terms, and consequently ended up distorting the meaning somewhat.
You're correct that, as described, the algorithm itself would have to compute the next key in the sequence, and that's where the major error occurs. In Brown's model, there's only one key, so of course it could be brute-forced (if the algorithm were known). Presumably the successive keys are determined by the following characters, e.g. if the text begins with "Hj%s0", then 'H' would be the input to a function that returns a key to use for the second-generation ciphertext, which might be "aui$@". To get the second key you'd then use the second character of this ('u') as the input to the key-generation algorithm, to produce the third-generation ciphertext, and so on. In other words, the content itself at each stage of decryption would be used as the means of computing the key to use to decrypt the next stage. That's where the "rotating cleartext" and "mutating strings" comes from, I believe.
As I said above, though, this is a flawed technique, since all of the keys except the first one are algorithmically determined. That being the case, as long as you know the algorithm and the first key, you can decrypt everything. The only thing stopping TRANSLTR from doing a successful brute-force analysis was the fact that they didn't know the algorithm.
In a real layered encryption scenario, all of the keys are independent, so you need to know all of the keys, the algorithm, and the key sequence.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
A bigger encryption-related plot hole, really, is the proposed chicken-and-egg scenario of Tankado's self-encrypted algorithm. It's simple to use an algorithm to encrypt, say, a text document containing that algorithm, so that's not the problematic part. The trouble is that Tankado is only offering buyers the key.
What were buyers supposed to be able to do with that key once they got it? In order to use the key to unlock the text containing the algorithm, they'd need the algorithm!
The key by itself is not particularly helpful in that scenario, because the algorithm itself is not known. They can try feeding that key to all of their "known" encryption algorithms, but none of these would work if Tankado's algorithm was something new and original. They'd be forced to try to reverse-engineer the algorithm with the help of the key--a much harder task, and one that cannot be assisted by brute-force techniques. And of course if they succeeded, they would no longer need the contents...
Now, even if Tankado provides a little binary application that lets you feed in the key and then does the decryption for you, it's trivial to disassemble binary code into a sequence of machine instructions that describe the algorithm. Had Tankado provided such a program along with his encrypted algorithm, the NSA folks would have taken that program apart in under an hour to get the algorithm. They'd still need the key to decrypt the rest of the package, but if that package only contained the algorithm details, why bother? At that point they'd already have what they were after.
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
Well, the program did have that input screen. If the encryption needed a key, it means that the algorythem was already in there. All they had to do was use the key to decrypt it and inside would be the source code, not another encryption. He was Digital Fortress to encrypt, not digital fortress itself, but the source code of digital fortress. So in all essence, he WAS encrypting a text file.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Right. He used DF to encrypt the source code (a text file) to DF. In order to decrypt that file, the key was input into a program that obviously implemented the DF algorithm. Since that program obviously knew how to use the key to do the decryption, the NSA would simply have had to run the program through a disassembler to discover the algorithm. Had they done so, they'd have had no need for the contents of the encrypted file.
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
