Xorcryption

[Joe]

Now, I guess encryption would go here, because its Network Security.

So, I know that xorcryption is about as secure as using a paper plate as a sheild in a nuclear war, but is there a way to make it extremely secure, yet still reversable?

Basically, heres what I would do:
1) Exchange token #1, in QWORD form. This is a random value.
2) Exchange token #2, in QWORD form, xorcrypted by token #1.
3) Exchange token #3, in QWORD form, xorcrypted by token #2 and then by #1.
4) Repeat until all paranoia is abolished.
5) The last token, and the previous token, are stored in memory. These combined into a 16-byte string will be the xorcryption key. Both clients have it, and anyone listening in has had a very hard time keeping up with us, although its still not possible.
6) for(int i = 0; i < strlen(Message); i++) { Message = Message ^ LocalKey[i Mod 16]; }
7) On the other side, for(int i = 0; i < strlen(Message); i++) { Message = Message ^ RemoteKey[i Mod 16]; }

Sent messages will use our local key (created from their random values). Recieved messages will use their remote key, created from our random values.

[iago]

If somebody could see your traffic, they could capture every key, and it wouldn't matter how many times you encrypted it. 

Also, if somebody could take a guess at what your data is, they could xor by the expected data and get your key.  That's the main attack used against WEP. 

[Sidoh]

Now, I guess encryption would go here, because its Network Security.

So, I know that xorcryption is about as secure as using a paper plate as a sheild in a nuclear war, but is there a way to make it extremely secure, yet still reversable?

Basically, heres what I would do:
1) Exchange token #1, in QWORD form. This is a random value.
2) Exchange token #2, in QWORD form, xorcrypted by token #1.
3) Exchange token #3, in QWORD form, xorcrypted by token #2 and then by #1.
4) Repeat until all paranoia is abolished.
5) The last token, and the previous token, are stored in memory. These combined into a 16-byte string will be the xorcryption key. Both clients have it, and anyone listening in has had a very hard time keeping up with us, although its still not possible.
6) for(int i = 0; i < strlen(Message); i++) { Message = Message ^ LocalKey[i Mod 16]; }
7) On the other side, for(int i = 0; i < strlen(Message); i++) { Message = Message ^ RemoteKey[i Mod 16]; }

Sent messages will use our local key (created from their random values). Recieved messages will use their remote key, created from our random values.

This, with a few revisions, is often referred to as "one time padding".  It works under the following conditions:

• The key is exactly as long as the message to encrypt (or longer)
• The key is only used once
• The key is kept secret

Your model doesn't follow any of these parameters, so basically it sucks.  :)

[iago]

Yes, that's the only form that a xor-encryption will work. 

Incidentally, here's another problem: when you encrypt anything without moving the characters/bits around randomly, it's possible to use statistical analyses.  Since there are only a certain number of alphabetic characters, and certain ones tend to appear near each other, it's possible to bruteforce it much more easily. 

Also, another attack: take 2 16-byte blocks.  Xor them with each other.  Now the encryption key is gone, and all that's left is 2 english strings xor'ed with each other.  There will be very few combinations that work to make actual letters.  It should be pretty quick and easy to bruteforce it from there.  And once you have a single 16-byte block, it's game over. 

And by the way, this statement:

Both clients have it, and anyone listening in has had a very hard time keeping up with us, although its still not possible.

Is totally false.  If the listener (say, Cathy) knows what the senders (Bob and Alice, of course) are doing, then Cathy can easily capture all the important information and use it just as easily ad Bob or Alice. 

And by the way, when talking about encryption, it's usually Alice encrypting a message to send to Bob, while Cathy is trying to listen in.  The A B C makes life easy. 

[Sidoh]

Hehe, Bob and Alice own.  You should be the listener though, iago!  ;)

[iago]

I'm afraid that there's no room for Ron in this farce we call "cryptography". .

Here is  complete list of characters, though:
http://en.wikipedia.org/wiki/Alice_and_Bob

And here's the story of Alice and Bob:
http://www.conceptlabs.co.uk/alicebob.html
I read part of that, and it seems pretty funny.  I'm looking forward to reading the entire thing. 

[Sidoh]

Hehe, yeah.  I remember reading something like that (though not ad in depth as wikipedia's article) in a crytpography book I bought a while ago.

[Joe]

Well, I was sort of wondering this. The only thing that is truely secure, IMO, is hashing, which totally kills data. Basically, if you know how to decrypt it, they do too. You have to share your key with the opposite side, which means you have to tell it to them.

If you're really paranoid you can say: iago, my key is "I like to eat bologna" on a phone call, and then iago decrypts your xorcrypted messages with that key. They can't get it that way. Perhaps this is possible to build the key into the client. However, the key can be disassembled right out of the client and become public knoledge (reference: AIM password roasting).

[iago]

First of all, how secure encryptio is have nothing to do with your opinion. 

With your form of encryption, it doesn't matter how the key is sent. 

The normal way to encrypt data is to use AES or DES (DES is typically used 3 times: either encrypt it 3 times, or encrypt it, decrypt it with a different key, and encrypt it again.  Both ways use 3 different keys).  Those algorithms don't just change the data, it also moves it around.  However, you need a shared key for this to work, which is difficult to transport. 

To have a secure shared key, pubic key encryption is used.  Yes, it's possible to bruteforce, but any encryption is.  The idea behind public key cryptography is that you generate a random private key, then derive a public key:
public_key = g^private_key % k, where g is some well known prime number and k is a large well-known value (on the order of 128 bytes)

Once you've done that, you can encrypt data with the public key, and it can only be decrypted (in any reasonable time) by the person with the corresponding private key.  The encryption is done this way:
encrypted_data = public_key^data % k
This is very slow to do, however, which is why DES or AES is used. 

I can't really explain how DES/AES work, because it's a lengthy process.  Check wikipedia or google for more information on them. 

[Joe]

But what I'm saying is that you have to give them one of the keys. They have your key now. I'm not sure which one it is and which it functions for, but you send your key (either private or public, asuming public) and its packetlogged. Badabingbadaboom. They can now send messages and be proven its from you (or read your messages, not sure which one).

Something like this is the WAR3 server signatures. JavaOp checks these just fine, because we know how to decrypt the private messages to the client. We know the values needed to decrypt this and check it against an IP.

[iago]

But what I'm saying is that you have to give them one of the keys. They have your key now. I'm not sure which one it is and which it functions for, but you send your key (either private or public, asuming public) and its packetlogged. Badabingbadaboom. They can now send messages and be proven its from you (or read your messages, not sure which one).

Ok, you're right.  So this is what you do. 

*tries hard to remember*

First, public/private keys work both ways. Something encrypted with a public key can only be decrypted with the corresponding private key, and something encrypted with a private key can only be decrypted by the corresponding public key.  Now, you:

- Generate the message you want to send
- Generate a SHA1 of the message, encrypt the SHA1 with your private key
- Prepend that to the beginning of the message
- Encrypt the entire message with the other person's public key
- Send it
- They decrypt it with their private key
- They decrypt the SHA1 with your public key
- They verify the SHA1

Now, they have:
- Proof that it was from you (since you encrypted the SHA)
- Proof that it was intended for them (since it was encrypted with their key)
- Proof that it wasn't tampered with in transit (since the SHA1 can't be re-encrypted, and it wouldn't match if it was changed)

Sounds perfect? Wellll, there's still one problem.  What is it?

[Sidoh]

Well, you've not established how the keys were transmitted between the parties in a secure channel, but I think in this example, we're assuming that it is possible.

* Sidoh thinks.

Hmm, I wrote it down.  Here's what I came up with:

KEY:

Private      Public
P1      N1
P2      N2

m - Message
e - Encrypted message, prepended with encrypted SHA1 of message
k - encrypted message hash

N2(P1(sha1(m)) + m) --(TRANSMIT)-->

P2(em) ---> k + m

N1(k) must = sha1(m)

I'm not sure what's wrong with it other than there was no established method of transmitting the keys securely.  This also assumes the public and private keys have no reversible properties, I guess.

[iago]

Well, the keys are public, so they can be sent into the open, posted on a website, sent through email, etc., they don't have to be hidden. 

But you're right, though.  The weakness is that it's vulnerable to a man-in-the-middle attack. 

Alice [public_key_alice] --> Bob

Could turn into

Alice [public_key_alice] -> Cathy [public_key_cathy] -> Bob

And vice versa, for Bob.  Then Cathy can decrypt what she has to, and re-encrypt it with her private key, both ways. 

The only realy defense for this is using an key escrow service, which opens a whole other can of worms. 

[Joe]

Alice [public_key_alice] -> Cathy [public_key_cathy] -> Bob

And vice versa, for Bob.  Then Cathy can decrypt what she has to, and re-encrypt it with her private key, both ways.

Bingo.

[iago]

Alice [public_key_alice] -> Cathy [public_key_cathy] -> Bob

And vice versa, for Bob.  Then Cathy can decrypt what she has to, and re-encrypt it with her private key, both ways.

Bingo.

Duh, I was the one who proposed that there was a problem. 

The only trick is, it's nearly impossible to have that situation.  Cathy has to be on the same LAN segment as either Bob or Alice, and she has to know exactly what she's looking for and targetting.  It's easy to sniff unencrypted traffic off the LAN segment, but I don't think I've ever heard of anybody performing a MITM attack. 

Also, if a MITM attack occurs on most software (any web browser, gaim-encryption, ssh, etc.) you get a warning.  The reason is, it remembers the public key, and if it changes, then an attack might be happening.  Most people just ignore the warning, but it still exists..