Author Topic: Xorcryption (Read 8358 times)

Joe · « **on:** October 27, 2005, 11:53:51 pm »

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 · « **Reply #1 on:** October 28, 2005, 08:42:26 am »

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 · « **Reply #2 on:** October 28, 2005, 12:04:19 pm »

Quote from: Joe[e2] on October 27, 2005, 11:53:51 pm

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 · « **Reply #3 on:** October 28, 2005, 07:03:04 pm »

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:

Quote

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 · « **Reply #4 on:** October 28, 2005, 08:27:18 pm »

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

iago · « **Reply #5 on:** October 28, 2005, 08:34:03 pm »

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 · « **Reply #6 on:** October 28, 2005, 09:47:53 pm »

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 · « **Reply #7 on:** October 30, 2005, 07:32:19 pm »

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 · « **Reply #8 on:** October 30, 2005, 09:19:31 pm »

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 · « **Reply #9 on:** October 30, 2005, 11:02:51 pm »

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 · « **Reply #10 on:** October 31, 2005, 08:40:41 am »

Quote from: Joe[e2] on October 30, 2005, 11:02:51 pm

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 · « **Reply #11 on:** October 31, 2005, 01:32:37 pm »

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 · « **Reply #12 on:** October 31, 2005, 02:44:09 pm »

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 · « **Reply #13 on:** October 31, 2005, 06:21:00 pm »

Quote

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 · « **Reply #14 on:** October 31, 2005, 10:05:11 pm »

Quote from: Joe[e2] on October 31, 2005, 06:21:00 pm

Quote
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..

Sidoh · « **Reply #15 on:** October 31, 2005, 10:08:43 pm »

Quote from: iago on October 31, 2005, 10:05:11 pm

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..

Haha, that actually made me laugh. "Duh [...]"

Hehe, yeah. This is cool methodology, though. I've thoroughly enjoyed cryptography for about the year I've been interested (double statements ftw!).

Blaze · « **Reply #16 on:** November 01, 2005, 03:29:34 pm »

I want to learn more about it, do you have any good book titles?

Sidoh · « **Reply #17 on:** November 01, 2005, 04:50:29 pm »

I've done a bit of work in cryptography, especially since my science fair project was on it last year. They're nowhere near as in depth as books or other materials on this subject, though.

http://sidoh.dark-wire.net/Science%20Fair/2005/index.php
http://sidoh.dark-wire.net/?fuseaction=tutorials.view&id=4 is an article I wrote on Xor keyed cryptography. It's pretty simple and to the point.

Blaze · « **Reply #18 on:** November 01, 2005, 05:25:57 pm »

D',ôh'/¢/=¨>?"oƒ'BŠ#Mx#E!¥/="R–&4…'5à&Mx%`²¡.à¨4×$LO£>ê#D?&Z¸'3X(Eì'So$5à$U™&5àb@"#0U!`B!3X&4â%R9"3X"O³"v6(0U%D?'Z¸f@"'4?!D¸§.àcQ%#Cf§87¡%÷£/=£>ê#4â%R9¨2@(O³!v6¦2@'Uú%0'#«aC)h78£/=¨(ŠdU>¡>ê'1~#ˆê'2€&LO(aæ%3X!X?%Sõ%2Ý#Mx$E!¦/=%A+&dn¤/=#)¢%…ç¡.à"$Ô!Xý£2@%LO(Z¸£/=#1~&ˆê¡.à(Uú(0&#«#Eì'#«¥2@§54&3¹%BŠ(+7$,*"0U!4â#R9(#«#O³'v6§>ê%6L!2Ý%Sõ"LO%aæa@"$X?(Sõc@""$Ô'Xý$0U&4?'Teb@"¢2@$[…c@"&R–'4…¢2@'4?&8Ôd@"£/=&.›'Vø'Mx%E!¤>ê¥54%Cfe@"%6¼$MB¢>ê#1~#ˆê(GK"LO&aæ¢.à&X?&Sõ¥>ê#U™$,*¤>ê$Eì(#«§2@£54"3¹$BŠ(LO&aæ#0U(4â"R9&0U(O³'v6'BŠ(Mx(E!d@"d'/#<¢¡.à(#«&oƒ"5à'+7#,*#3X§54!3¹$0U&bG(Eá§2@'$Ô&Xý'#«%4?#Ted@"¨2@%[…§.à$0U!`B%Vø#^ã%<—£/=%6L#BŠ'Vø#1~¤%÷¨>ê$aæ#c¦¦4×"bC!1!&0U%0U$`B'3X!@Î&2Ý#0U¦54(3¹g@"&Cfg@&£/="0U$`B!#«$n?"^Ø£2@%@Î'2Ý(BŠ%#«"B-h@&§!†%

PrK:15E00AC7055302A1014D008D004A0018
PuK: 23A005F7029322410C4D0FAD0CAA21182CB00161

Interesting program there, except it crashes easy.

Sidoh · « **Reply #19 on:** November 01, 2005, 05:30:34 pm »

Quote

Hehe, made you decrypt.

<_<

Yeah, thats because of a bug I fixed before I submited this to science fair, I just haven't uploaded the fixed version yet.

Sidoh · « **Reply #20 on:** November 01, 2005, 05:31:28 pm »

I%,=%,p'fn"T§!fn&^ã$(7!(7!Kú(†q(@É!LZ%(7(iy%tã%†q!^ã#Qr¥.#$Qr§.##Tù(tã(Tù&(7f/"#LZ%(7%IÈ'(7$Tù!†q(k«&(7!†q¡!|C

iago · « **Reply #21 on:** November 01, 2005, 07:28:25 pm »

There's a book called Applied Cryptography, which is apparently really good.

I've never actually read any real books on cryptography, but I learned a whole lot reverse engineering War3's login. I ended up reading a lot of papers and sites on the subject. You can find all sorts of stuff by surfing Google, Wikipedia, and Mathworld.

News:

Author Topic: Xorcryption (Read 8358 times)