Secure XOR

If you use the same key many times, then probability search could eventually crack it by looking for known patterns.
The cracker would need to know something about the contents of the encrypted data, though.

That''s what I''m saying though..the key wouldn''t repeat.

------------------------------------------------------------
Timothy Barnes | War Charity | 2003.

That''s known as OTP (one time pad) encryption, and is provably uncrackable. Its only weakness is in the pad (XORed key) generation; if the key can be intercepted or its production replicated, the code is broken.

---

How appropriate. You fight like a cow.

I''m thinking it''s virtually uncrackable too (without knowing the key of course)

------------------------------------------------------------
Timothy Barnes | War Charity | 2003.

I believe the government uses it. With special drives that burn off the data after its read, used to encrypt and transmit back home. where the only other copy of the disk gets its data read, burned off, and used to decrypt the data.

OTPs are the only proven uncrackable encryption.

I like pie.

I suppose by uncrackable you mean can only be broken via plain brute force?

Actually he means uncrackable.
"My number: 3947472"
might be decrypted as
"My number: 2384769"
or
"Buttsech anoyne?!?!?!111!"
or more likely, something like
"pHh4hnf9n+8n9j7"
if you "guess wrong"

Since there are as many possible keys as there are possible texts (since both are of equal length), there is no point in even trying a brute force approach. Thus it is uncrackable.

Clarification: There is no point in trying because there's no way of knowing when you found the right key.

[edited by - Cestps on August 4, 2003 7:03:27 PM]

quote:

---

Original post by Monder
I suppose by uncrackable you mean can only be broken via plain brute force?

---

We mean uncrackable. Think about it.

In simple math, this encryption is equivalent to

Tell me the value of X, when Y is unknown, and Z is 12:

X + Y = Z

quote:

---

Original post by C-Junkie

quote:

---

Original post by Monder
I suppose by uncrackable you mean can only be broken via plain brute force?

---

We mean uncrackable. Think about it.

In simple math, this encryption is equivalent to

Tell me the value of X, when Y is unknown, and Z is 12:

X + Y = Z

---

If you were ever told the meaning of any encrypted data, you could calculate the key, or at least part of the key, and decode everything else of equal or lesser length.

You couldn''t figure out X + Y = 12 alone but if someone told you that X(original data) = 4, you could figure out Y(the key) and use it to to solve all other instances of Z(encrypted data). One little information leak and suddenly all your hidden data is known.

quote:

---

Original post by smart_idiot
You couldn''t figure out X + Y = 12 alone but if someone told you that X(original data) = 4, you could figure out Y(the key) and use it to to solve all other instances of Z(encrypted data). One little information leak and suddenly all your hidden data is known.

---

Which is why it''s a One Time Pad. Each bit of the key is only ever used to encrypt one bit of plaintext.

---

How appropriate. You fight like a cow.

Sounds good to me ^_^

------------------------------------------------------------
Timothy Barnes | War Charity | 2003.

quote:

---

Original post by nes8bit
That's what I'm saying though..the key wouldn't repeat.

------------------------------------------------------------
Timothy Barnes | War Charity | 2003.

---

use PI


[edited by - Xtremehobo on August 4, 2003 10:17:53 PM]

Are there any network protocals that encrypt packets like that?


If yes, is there a speed tradeoff?

quote:

---

Original post by Raymondo
Are there any network protocals that encrypt packets like that?


If yes, is there a speed tradeoff?

---

I think IPComp (IP Payload compresion protocol, rfc3173) supports encryption. It uses compression too to speed things up. I think you might be able to do it over PPP-CCP, not sure though.

quote:

---

Original post by Raymondo
Are there any network protocals that encrypt packets like that?

---

No. Ya see, the weakness with the OTP method is that the key itself must somehow be transmitted. This is the fundamental puzzle behind cryptography: A needs to tell B something, in such a way that C can''t tell what''s being said, even while hearing everything A is saying. In order for OTP to work, the key must be securely transfered beforehand (think of a CDR in a locked briefcase handcuffed to an agent) and never transmitted publically.

Want to make a protocol that does this? Simple. Just transmit the offset in the "pad" (file full of random data, which A and B each have a copy of) that''s being used for each packet. Never use the same range twice. But the real problem with OTP, and the reason why it is rarely, if ever, used today, is that it only works when a secure channel has been established sometime in the past.

If you''re worried about performance, it WOULD be possible to transfer an OTP key beforehand, using some other cryptosystem as a transport security method. Then the actual decryption, later on, would simply be a matter of fast XORs. But you''d be limited to the size of the key that had been transmitted, and anyways, modern computers can handle realtime encryption/decryption without issue.

---

How appropriate. You fight like a cow.

Sneftel, I''m working on the assumption the both nodes have aqquired the key prior to any encrypted data being transferred.


The reason I''m asking in the first place is because I''m curious about a good method for ensuring secure data transfer between a client and a server cluster for use in, for example, an MMOG.

More specifically, the encyption game data that relates to item information and the in-game financial systems.

My idea is that the client machine has the key build into the game executable, whereby assuming the game client is patched every few weeks, the key is inherently changed as a part of the update.

Seems pretty impractical though :/

The problem with using it over a network is that you need one bit of key for each bit of data transmitted. In other words, the key is just as large as the data it can encrypt. If you have a secure way of getting the key to somebody, why not just use that same method to send the data instead?

See that''s the cool part though. The way I''m thinking this is best implemented is when you have the key on a CD or something. Imagine having a 650mb encryption key that only so many people physically have. Now you can communicate between them completely securely.

Crazy...just crazy...

------------------------------------------------------------
Timothy Barnes | War Charity | 2003.