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.
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
Well, a dissasembler just take apart a program and shows it to you in hex values and the like. The source code is the actual programming such as C++ or ColdFusion, whatever it was written in. The probably couldn't have goten the algorithm from disassembleing it, but they probably could have found the key, depending on how encrypted the code was. But they're experts, I don't think they would have had a lot of trouble.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Disassemblers reduce an executable file to its individual machine-code instructions (i.e. assembly language). Those "hex values" represent "opcodes" (operation codes) that correspond to machine instructions at the most basic level, such as "JMP" to jump the execution flow to a specific memory address (for branching and looping), where the next machine instruction should be found, or "PUSH" and "POP" instructions to store/fetch data in memory registers.
These instructions are not as "readable" as higher-level programming languages like C, but a programmer can still use these instructions to recreate the algorithm (programmers today still read and write assembly language code for special purposes and reverse-engineering other people's algorithms). In effect, the machine instructions (like any form of source code) are just the implementation of an algorithm.
The key, on the other hand, would not have been discernable through a disassembly of the program. The key in a cryptographic system is usually used as input to the function, and would not be hard-coded anywhere in the program itself. (Otherwise it would be even more trivial to obtain and use.)
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
It wouold have to be, otherwise how would the program know what it was looking for. It's like a registration key, if the value you input is equal to AfhAgjFDSe256W46nS then set it to unlock, or decrypt. If it wasn't hardcoded anywhere then how would it know that AfhAgjFDSe256W46nS unlocks the program and FsdhwgStyhr534ASf3257 doesn't? An algorithm is a set of commands that execute based on the input. That way you can have multiple keys and not one certain key that could unlock any program with that encryption. It would almost HAVE to be in there somewhere. Perhaps extreemly hard to find, but it is still possible.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
No, that's not how modern encryption works. You don't embed the key in the program itself and match it against the user's input. The algorithm that the program implements is just a kind of translator (hence "TRANSLTR"). It takes as input the key and the text to be translated, and uses the algorithm to generate a result. If the key happens to be the *right* key, then the result is the encrypted or decrypted output we want; if you use the wrong key, you still get output, it's just that the output is gibberish because it was "mistranslated".
A simple example might help to clarify this. Suppose that the key were "BXDV", and we wanted to encrypt the phrase "HELLOTHERE". Having the just the key doesn't help us--we need to know what algorithm to use to do the encryption, i.e. how to *use* the key.
Suppose that our algorithm is a simple one: the ordinal value of the character in the key is added to the ordinal value of the character in the plaintext, in a modular way. In other words, we repeat the key over and over again until it matches the length of the plaintext, so if the plaintext were "HELLOTHERE" (10 characters), we'd repeat the 4-character key 2.5 times ("BXDVBXDVBX"). Then we'd add these letters to the plaintext, and any characters that end up larger than "Z" get wrapped around to the beginning of the alphabet. The first character of our encrypted output would be H+B = J, the second would be E+X = C, and so on:
HELLOTHERE
+BXDVBXDVBX
----------
JCPHQRLATC
The encrypted output would be "JCPHQRLATC".
Now, put yourself in the position of the person doing the decrypting. You can know the algorithm, and you can even know that the key is 4 characters long, but they key itself is still necessary to do the decryption. The key is not hard-coded in the algorithm anywhere (or in any implementation of the algorithm, compiled or otherwise)--the algorithm merely explains how to *use* the key. If you know that the key is "BXDV", and the ciphertext is "JCPHQRLATC", and you know the algorithm that was used to encrypt it, you can use that algorithm in reverse to obtain the plaintext:
JCPHQRLATC
-BXDVBXDVBX
----------
HELLOTHERE
Now, suppose you didn't know the key, and you decided to use brute force to figure it out. You know that the algorithm is expecting a 4-character key, so you decide to try "AAAA", "AAAB", "AAAC", and so on, until you find the correct key. When you try "AAAA", you get this:
JCPHQRLATC
-AAAAAAAAAA
----------
IBOGPQKZSB
When you try "AAAB" you get this:
JCPHQRLATC
-AAABAAABAA
----------
IBOFPQKYSB
The "right answer" is not hard-coded in the algorithm anywhere (or in any implementation of that algorithm, compiled or otherwise)--that's precisely why the algorithms were designed the way they are.
When you do your brute-force analysis and eventually get to testing "BXDV" as your key, you'll get "HELLOTHERE", but remember that to a computer this is just a translation task--it considers *all* of the output equally reasonable (or unreasonable). Of the 456,976 possible keys (26^4) for this algorithm, only one will produce "HELLOTHERE", but how does the computer know that "HELLOTHERE" is the "right answer"? It doesn't--it needs more information to do that.
To determine which of the 456,976 different outputs is most likely to be the "right answer", it has to make some assumptions about the language the document was written in, and look for dictionary words in the result. If we had assumed the original text was written in English, we'd be using an English dictionary, and spotting the pattern "HELLO" or "THERE" would cause that result to score more highly than the others. Through random chance, some of the other mistranslations may still contain accidental patterns (e.g. "DXGCATCHGW" contains "CATCH"), but we expect the most matches to occur in the properly translated version.
In short, the algorithm and the key are *always* independent of one another. The algorithm only specifies the parameters of the key--how long it needs to be (4 characters in our example), and what range of values it can contain (letters A-Z in our case).
There's no built-in, hard-coded key value to match against, and this makes the same algorithm usable by many different people--they can each have their own key, but use the same algorithm. That way if Alice wants to send an encrypted e-mail to Bob, she can use key "JWHS", and if Carol wants to send Dan an encrypted e-mail she can use key "OWLS". Both senders can use the same algorithm to do the encryption, but because they're using different keys they generate different ciphertext (even if their plaintext was identical). If the key were somehow hard-coded into the algorithm, everyone using that algorithm would have to use the same key
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
::light clicks above head:: I get it now, I'm stupid ^_^ I was thinking more along the lines of registration keys, there has to be some list of those to work. Duh. Thanks for the explaination.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Registration keys are something different, yes, but there's still no requirement that there be any "list" of valid registration codes.
Many software packages that ask for a registration code ask you for some other piece of information--a "registration name", "serial number", or "registration ID". That value is used as input to a function that performs a one-way mapping to a registration code. When you enter the registration code, the software just compares what you typed to the result it got from the one-way mapping.
Again, a simple example might help. Suppose that the program prompts you for two values: (1) your name, and (2) your registration code. You enter "John Smith" for the name.
The program will use an algorithm that does something with "John Smith" to determine what the corresponding registration code should be. Perhaps the algorithm just adds up the ordinal values of each of the characters (A = 1, Z = 26, spaces and punctuation = 0, etc.) and sums them together:
J = 10
O = 15
H = 8
N = 14
S = 19
M = 13
I = 9
T = 20
H = 8
---------
116
The program essentially uses some piece of input (in this case your "registration name") to compute what the matching registration code should be. Here, with this simple algorithm, "John Smith" would need to use a registration code of "116" to match properly (it's called a "one-way function" or "hash" because the algorithm only works in one direction--there's no way (or too many ways) to get "John Smith" from "116").
Obviously real software protects itself with more complicated algorithms, sometimes using serial numbers from some of your hardware components, or the machine's network name/address or somesuch as keys to help obscure things. That said, there's still no "list" of valid codes stored in the program.
Encryption used this way just relies on the obscurity of the algorithm itself--as long as you don't know how to convert "John Smith" into the proper registration code, it's secure. The folks who crack software like this don't use brute-force decryption techniques (though they could, if they had some idea what the parameters of the valid registration codes were, e.g. length, alphabet, etc.). It's usually far quicker and easier to run the program through a disassembler and locate the instruction sequence that gets performed on the input. Once you know what gets done to the input, and in what order, you essentially have the algorithm, and can generate registration codes for any arbitrary input thereafter. That's why this kind of so-called "security through obscurity" is considered extremely weak in the computer security business.
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
Oh, ok, I see now. So much I didn't understand (some much I still don't understand), and just assumed. I guess that's what I will be going to college for, eh?
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Now, in Brown's version, the "pass-key" that Tankado's program is asking for all but certainly *was* hard-coded into the program itself, since there was no other user input available to generate a matching code. The program only prompted for one thing--the pass-key. There was no "registration name" or "ID" or "serial number" or additional "access code" that could have been used to algorithmically create the matching pass-key.
Since in Brown's version the pass-key had to be encoded in the program itself, it's a bit silly that the NSA folks weren't able to determine it directly after disassembling the program. Remember the scene near the end with the coders rushing in with the disassembled code? Soshi runs in and says, "We isolated the worm's execute commands--have a look at the programming! Look what it's planning to do!" They had obviously just disassembled the program and reconstructed its algorithm. Having done that, the hard-coded pass-key should have been trivial to spot.
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
Yea, that is true, unless the pass key was somewhere on the web and the program accessed that site. It is possible that they might have overlooked that, although it is doubtful.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
True, it could have been located elsewhere, but in that case they'd have seen that fact in the disassembled code, which would have to have the website or IP address/port number in it somewhere. One way or another, disassembly of the program would give everything away.
Of course this and other cryptography-related plot-holes throughout the book could be semi-intentional on Brown's part, for a variety of reasons:
(1) He's trying to take a very dense and complicated subject and reduce it to something simple enough for someone without a degree in mathematics or computer science to grasp. Inevitably when this happens some of the detail is lost, as things get oversimplified.
(2) He's writing with movie rights in mind. This book would be trivial to adapt for the screen, and there are some sections in particular that strongly suggest that Brown was thinking about this from the start. Consider the climactic scene in the control room, where the "vis-rep" provides a real-time animated display of hackers making their way past defenses and closer to the NSA databank.
(3) Brown may have been trying to intentionally keep things at a relatively abstract level so as not to give wrong-minded readers dangerous information. This is common in books that discuss things like how to build a nuclear weapon, etc. Keeping the technical details at an abstract level with just some 'teasers' of detail is often a conscious decision on the writer's part.
(4) It's possible he simply made mistakes. My sense is that he does not understand modern cryptography very well. He seems well-versed in classical cryptosystems, but his claim that it all started with Caesar is patently false, which makes me question the rest of his cryptological knowledge. The book's acknowledgements suggest that he consulted with a couple of ex-NSA cryptographers, and while I'm sure they provided some details to add realism to his story, the value of their information is proportional to the quality of the questions Brown asked of them (and what they felt they were able to divulge, even anonymously). Important facts could well have been left out, and Brown may not have known the subject well enough to recognize the holes in his story these omissions would leave.
In the end, the story remains enjoyable in spite of these holes, and most readers won't even notice them. It's only a tough read for those who know the subject matter well enough to spot the technical inaccuracies. But then, that's where the educational opportunities lie, right? Forums like this one let people ask the "is this really possible" question, and get answers from those who have them. Self-enrichment opportunities for the curious
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
I concure(sp?) completely. I thought it funny how he did the real-time hackers. That was great. It's too bad that it's really not like that, it would make things oh-so more interesting.
|
WKShadow
Beloved Angel
Reged: 06/02/04
Posts: 79
Loc: Myrtle Beach, SC
|
|
Dan brown should consult you for his next book 
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Quote:
WKShadow said:
Dan brown should consult you for his next book
Nah, I think the trend in his writing suggests that he's found his strong points in symbology, art history, and secret societies, and is shying away from cryptography--at least in the modern sense.
As I mentioned earlier, his understanding of cryptography seems to trail off somewhere around the beginning of the age of computer-based cryptosystems. He adores the Caesar Box cipher and other basic transliteration techniques that have been around for thousands of years, but while you might find these in brain-teaser books and IQ tests, you won't find them in practical use these days.
The reason is simple--a modern computer can iterate through millions of combinations and permutations in a second, so without being particularly clever you can decode any of these cryptosystems--brute force wins. Those ancient cryptosystems were secure before computers came along only because the brute force approach was impractical. If there are a hundred million possible ways to transliterate a key, a human being would require an enormous amount of time to work it out by hand. A computer can try all of those possibilities in a few seconds.
Modern cryptographic techniques are based on "hard" mathematical problems--problems that take computers a prohibitively long time to solve. There are many operations that computers can do extremely quickly, but there are a few that still require a lot of time, like finding all of the factors of a huge number to determine whether it's prime or not. If you choose a big enough number, and you have to do this once for every possible key you want to try, you suddenly slow things down to the point where the brute force approach would take a year, ten years, or even a hundred years to work.
Since the advent of public-key cryptography in the 1970's, the real magic has been in the keys themselves, not in the algorithms. In fact, the algorithms themselves are well-known and widely published. Anyone who wants to know how an algorithm like RSA, SHA1, IDEA, or Blowfish works can download the information from the web. Knowing that information won't help you crack something encrypted with those cryptosystems. Their strength relies on the fact that they use large keys to do their encryption, and that it's extremely time-consuming for a computer to try all possible keys to find the one that works.
Brown's research in this area was sadly limited, particularly for a book whose subject matter was modern cryptography. I gather that he wasn't particularly computer-literate at that time either, which may explain part of it. He carelessly refers to a "64-bit" key as if it had 64 bytes, when in fact it would only have 8 (there are 8 bits in one byte). Tankado's "64-bit" key should have had just 8 letters to it, not 64.
I believe Brown is fascinated by cryptography, but has only studied it in the classical sense, and may lack the background in computer science to understand how machines have changed the game in recent years. He clearly understands the issues, it's the mechanics he fumbles with.
We can forgive him for the fact that this was his first book, and that he was not a computer scientist or mathematician. Viewed in that light, Digital Fortress is remarkably good I think, though, that in his later books he migrated toward his strengths, which may explain why The DaVinci Code is the book he's best known for.
|
Pilaar39
stranger
Reged: 08/02/04
Posts: 2
Loc: Toronto, ON, Canada
|
|
Quote:
Arras said:
Brown's research in this area was sadly limited, particularly for a book whose subject matter was modern cryptography. I gather that he wasn't particularly computer-literate at that time either, which may explain part of it. He carelessly refers to a "64-bit" key as if it had 64 bytes, when in fact it would only have 8 (there are 8 bits in one byte). Tankado's "64-bit" key should have had just 8 letters to it, not 64.
Yeah, I noticed that too.
I was also amused about the supercomputer NSA was using. A 3 million cpu parallel processor? I dunno, but I somehow doubt it.
Furthermore, I question the fact that it would take 30 to 40 minutes to shut down a database. I mean, why not just cut the power? Yes, some data might get corrupted, but in the long run, isn't that better than giving it out to the whole world?
|
Dave_Howe
stranger
Reged: 12/13/04
Posts: 4
Loc: Manchester England
|
|
Joining this one late but
a)the cryptographically locked document shows a interface (ie, a "type key here" box) so is obviously an executable program. that being true, it is possible to write such a program in such a way that the decryption process generates more program code just ahead of execution - so the correct creation of the decryption code depends on having got the bit of the key used so far right...
b) the initial description sounds much like a composite cypher - ie, multistages, some of which are weaker than others, but are merely there to disguise the plaintext. One viable approach is to zip the file (disguises length, hides repeating patterns,t hat sort of thing) then xor the first byte with the second byte, the second with the third, the third.. well, you get the idea. without knowing what this obscuring step is, you have to guess if you have found valid plaintext or not. XOR is a surprisingly common tool for this sort of thing - a much, much more secure form of DES is called DESX - this is the crypto used by the MS EFS, and consists merely of xoring the plaintext with a 64 bit key, applying des, then xoring the cryptotext with another 64 bit key to make classical DES brute force analysis impossible.
c) I *do* have a question though. is the bit about the hungarian made up of whole cloth? I have been websearching for a while, and could find no mention of him or his method.
|
txtjunkie
stranger
Reged: 02/19/05
Posts: 1
|
|
Okay, beyond the possibility if you can develop a rotating clear-text I saw one other plothole.
1. If Strathmore wanted to make additions to the original code he would likely never get a chance. If everything was to go as planned the corporation that made the highest bid would win the key and enter it into their existing download of the source code. Plus the size of the download file would change and that might throw up a flag. Granted, the situation had changed since Tankado died and it was to be released as free source but the key would still have to be given. If the key didn't work on some downloads that might definatly raise some eyebrows.
Maybe I missed something but I don't see how. Let me know please.
|
Lightstar
stranger
Reged: 03/28/05
Posts: 4
Loc: Florida
|
|
At the time Strathmore killed Chartrukian you have to remember, he was still unaware that Digital Fortress was a virus, he thought it was the rotating cleartext encryption.
Hulohot knew the names of the victims (most likely) because strathmore uploaded their profiles to his monocle computer.
--------------------
-Lightstar
You've just been blinded by the starlight.
|
8549176320abc
enthusiast
Reged: 05/02/05
Posts: 219
Loc: UK
|
|
The ever so fond Bergorfsky principal simply does not work and I will tell you why: say you have an algorithem with a huge key and you try to solve it with every posible key - each atempt will give off a stream of values in the form of letters (perhaps numbers also) if there are enough combinations you are mathematicaly garanteed to find not only the pain text result but a completly diferent statement also in perfect English- this is why the one time pad cypher is inpenetrable (the idea being that the vigenere cypher is used with a random key with the same lenght as the plaintext)
An example: suppose I send the message "ROCKISBAD" (rock is bad) with a random key (say "asdfghjkl") and get "RGFPOZKKO" I could have also sent the message "IAMNOTDAN" (I am not Dan) using the key "JGTCAGHKB" and got the same result so how does the TRANSLTR know which I have sent - it can't without knowing my key which it doesn't!
--------------------
Governments offer us safety for our freedom. It is by seeing this safety as false that we are freed.
Edited by 8549176320abc (05/02/05 08:16 AM)
|
MathInYUL
stranger
Reged: 05/02/05
Posts: 1
|
|
First off, the "Bergorfsky principal" dosen't exist. It's never clearly stated in the book, and has no basis in reality. However, the idea that he's getting at (that any contemporary non-quantum cipher can theoretically be brute-forced in a certain time period by a certain number of machines) is widely accepted. The "game" of cryptosystems is to make the "certain time" and "certain number of machines" so large as to make them (physically) not possible.
I'll give you an example. The fastest supercomputer in the world (BlueGene/L) is current rated at 70 TFlops - which means it can perform 70 trillion operations per second. When it's fully on-line, it should be able to hit somewhere around 100 TFlops (note that both these numbers are for problems specifically optimized and designed for that machine). To be conservative, if we got BlueGene/L running at 150 TFlops (which should be possible in a few years), and assuming it could run at that speed to decode an AES message (AES being the newest government standard encryption) forever, it would have to run for about 14000 times the current age of the universe to guarentee a message decryption. So while it's possible, it's a bit too long to be practical.
Besides, no cryptographer would make a law about messahe decrypts like that - that's someone else's job, Cryptography is about breaking the code mathematically. Deciding if an outcome is an answer ("ROCKISBAD" vs. "NGFDCJBAD") is a totally different problem. That would require a whole new understanding of language processing.
| |
Previous
Index
Next
Threaded
Edit
Reply
Quote
[Re: