Operation Swordfish

[daSnoop]

Wargames.

Old techniques, yes, but the most accurate I've seen in Hollywood.  Only took a little suspension of belief to enjoy it.

[Rookie One]

Isn't the problem with encryption of individual characters specifically BECAUSE you'd encrypt every character (or byte) with a different algorythm?  The key wouldn't be the size of the file, it would be several hundred times the file if it was a complex algorythm.  It would be like storing five thousand PGP keys in a 5kB data file.  Encrypting a megabyte of data that way would produce a file easily a terrabyte in length, with most of it being the encryption key alone.  

On a larger scale it would probably be feasible, though.  For instance, you break up one file into a few dozen RARs (or other split-file programs), encrypt each file portion with a different algorythm and a different key.  

[Astromarine]

rookie - no, go read the link I gave if you're interested. It is the same function for each character (XOR)

it like this (fictional example, don't wanna do the math):

"A" XOR "*" = ">". BUT "B" XOR "&" = ">". So, if all you see is ">", *how do you know* which was the original character, if you don't know if I used "*" or "&" as the key? So, to encrypt 10 characters you get a string with 10 random characters and xor it with the original data. Then you give the *key* to the receiver in a secure way (by hand) and so only *he* knows the second operator in the XOR operation.

Again, I am a poor teacher and I am NOT a crypto expert. go get the link I gave

[Rookie One]

I dunno, if it uses the same algorythm it would still be crackable, wouldn't it?

[Jaz]

Technically, *anything* is crackable, with enough resources thrown at it. Brute force will eventually overcome the encryption, just that with good encryption, the math works out to taking a computer that can process data far faster than what we can possibly do now, and it would still take (in a worst-case situation) more time than the universe has been around SO FAR.


As for the encryption method being the same algorithm, it shouldn't matter. The algorithm is trivial for the actual encryption (generally just adding, or XOR'ing), it's the *key* that becomes impossible. Try this as a quick exercise:

Say you want to encode the word "SECRET". You have a simple key, "ABCDEF". You basically do addition on the letter values.

   S E C R E T                     19   5  3 18 5 20
+ A B C D E F                  +   1  2  3   4  5  6
-----------------           ----------------------
   T G F V J Z                     20 7 6 22 10 26

So "SECRET" encoded is "TGFVJZ".
(I hope that should be relatively easy to understand)

Now instead of using something simple like "ABCDE", take an entire character set (like all the characters in the ASCII table) and randomly generate them by, say, capturing weather data and converting it to a binary file. Unless someone has the actual key that you used (so they can do subtraction), it will be near-impossible to break the encryption. Thus, the algorithm (add two characters together) is very simple and well-known. But it is infinitely complex due to the depth of the keyspace (the number of possible combinations of data based on the character set used and length of data).

And yes, it would also be almost impossible to generate the same binary file from weather data if done properly (since, after all, wind data may be different at a sensor 5 feet away from the collector), so generating a unique key isn't a problem.

[Astromarine]

exactly. but the reason I say "impossible" and not "near impossible" is viewable in your "sum" example - you have a binary operation generating your result. It is a simple operation and it has an interesting property: you cannot vary one of the operators and obtain the same solution - hence guaranteeing the "uniqueness" of the encoded data, which is essential for decryption - but if you DON'T HAVE one of the operands, only the solution, there is an infinite amount of solutions for x,y (taking sum(x,y)=z, z being the encrypted data). not all the computers in the world can help you there. They can brute force at will, but they cannot decide from the myriad of possible solutions.

[Rookie One]

So... why isn't it used more?  

[Astromarine]

oh, it is. trust me. but the use it has is not what used to think as "encrypted communications". You can't use it to encrypt a line, like SSL or equivalent. E-mails *could* be done, but they are impractical.

The key to this algorythm is that the key must be used *for that time only*, or for a limited number of times. otherwise, statistical analyis may get it. What it *can* be used for, for example, is this:

Say you have an R&D department divided between 2 locations. they have to trade communications between them, but it must be encrypted. this means e-mail, text documents, etc. What you do is have the heads of both departments meet once a week, or once a month (no more than that) and generate a few random key files together. Say 10. Then, for the following month, all comms between those 2 departments are encrypted with one of those key files. The receiver of the communication runs the XOR operation on all key files, and checks the output for all 10 "result" files to see which one is correct. Bingo, you have ultra-secure communication. The problem is the "key swapping", because it has to be done in a secure way. The advantage of keypair algorythms is that the public key can be traded thru insecure channels, and that is why it is used more often.

[Rookie One]

Ah... so it's sort of useless unless you have a confirmed secure channel anyway (because the key would be at least as necessary as the data itself for transfer), while there can be free sharing of keys with all those $_-bit algorythms... cool.  

Just seems sort of silly if, even if it's so great, the key is 1: as long as the original data and 2: as important as the original data.  It would make things harder, but the same methods needed to grab the stuff would be the same.  

[Hydra]

Sorry this is a bit off-topic now, but to whoever mentioned that gigaquads have no relation to the real world, I think a quad is the equivalent of a bit in quantum computing (but don't quote me on that ). So a gigaquad would be 2^30 of those.
I could be wrong.

[Rookie One]

Still seems sorta silly.  We'd at least go into the terrabyte and petabyte range before even thinking into quads.  Quads would be, like, twenty years from now, not ten.  ;)  

[JcDenton999]

the equivalent of bit in quantum computing is qbit (and it consists of the states 0 1 and 2 if i remember that correctly)! i had to do a work bout a related topic for school

[Hydra]

Interesting JcDenton999, that sounds like a 'trit' (trinary digit). I think you're right about the bits in quantum computing being called qbits though, or possibly quits. Maybe a quad is the equivalent of a byte?

[JcDenton999]

ah yeah, trit's got those three statess, but im sure its qbits and not quits