Encryption and plain-text attacks

Let me repeat what I think you said in a pseudocode fashion, just to see if I understand what you're getting at:

function CBC (key,vector,data);Original method:easilyhacked = CBC(somekey, vector,  data);Are you suggesting this?:superkey = CBC(key,vector,key);hardtohack = CBC(superkey,vector,data);

I had a different interpretation.

Encrypt:
superkey = CBC(key,vector,data)
hardtohack = CBC(key,superkey,data)

Decrypt:
data = CBC^-1(key,superkey,hardtohack)


Either way though, I don't see how it would be more secure. In your case, a key is a key so it doesn't matter which one is used, the known-plaintext attack is still possible. And in my case, it seems that if you introduce a correlation between the key and the IV it would be a lot easier to break than it would with a random uncorrelated IV. It's also possible we both interpreted it incorrectly.

Re OP

Not.
And for you question the text book answer would be, not if it will not be a one time keypad.

BTW what for do you need it? And why are you posting this on a game developer forums? Possibility of finding someone qualified to answer are low here. While I do have some experience with cryptography, you need cryptoanalysis. If you want do something serious be careful, or you'd seriously nail you face.

For all you know, your encryption scheme could have a weakness when you encrypt the key with the key.

People figured out how to attack some encryptions using known plaintext. Because it is often the case that you can know part of the plaintext, trying to see if an encryption scheme has a known plaintext flaw is a pretty common bit of theoretical cracking.

And it doesn't always have to be the first bytes that must be known for the encryption to be vunerable.

Nobody has a proven secure cypher (except one-time-key pads, and quantum). If you want a good and secure system, research the appropriate kind of cypher for your problem, and talk to experts who know of flaws.

sorry if this is completely incorrect.

If you were to encrypt your origional data with one key, producing the resultant cyphertext.

That cyphertext is unknown, because the key is unknown.

If you were then to encrypt that cyphertext with another key, you then have no known plaintext/cyphertext pairs, which would stop a known plaintext attack?

What your saying seems similar to what cyphersabre does. They discard a set number of bytes after initialization, due to some problems rc4 has. (with the first few bytes being able to be used in an attack).

I don't think it has anything to do with a known plaintext attack.

hope this helps.

Quote:

Original post by hplus0603 Suppose I were to use a block cipher like X-Tea in Cipher Block Chaining mode. If what I'm encrypting has a known header, then a known-plain-text attack could conceivably be done. I believe this is how WiFi key catchers work -- they take advantage of knowing the value of the first byte of each packet. My question is: Could one device used to prevent this attack be the key itself? Suppose I first encrypt the key with itself, but don't store the result, and then keep encrypting the data in CBC mode. Wouldn't this remove the advantage of knowing the plain text? When decrypting, I again encrypt the key with itself to initialize the decryption stream, and then decrypt the actual data. I *believe* that this is different from just using another key, because in CBC mode the key is still the same; the data just gets scrambled. However, here's where I'm not 100% sure -- am I reading this wrong?

I don't think it's good idea to enctypt key with itself. It will almost certanly reduce security of the key by some non-small amount. chances are some non-small portion of keys will give same result when encrypted by themselves. Also, encrypting key with itself sounds like attempt at making poor man's hash function,; most definately some existing hash function designed with security in mind and not yet breaked would work better.

Additionally, if i undestood what you are saying right, if attacker is using custom software, he won't need the key, "encrypted key" will suffice.

I would recommend using good, proven in usage encryption algorithm like blowfish that has not yet been broken with known plaintext and with which it's quite unlikely it will be broken before your software goes outdated. And never ever send key encrypted by itself because (IIRC) security of message containing the known key in it so is not considered when designing ciphers.

The guys who design good encryption schemes (e.g. Bruce Schneier) are smart, and specialize in the topic. Today's encryption methods have many years of technological development and a lot of advanced math behind them, designed not to be breakable with plaintext attack. Good encryption methods are generally hard to come by.

As for wifi, IIRC it just send key in plaintext, or does something similarly stupid.

If you worry about this, you are obviously transmitting the launch codes for nuclear weapons...!
For most normal people, X-TEA is perfectly suitable, 100 times overpowered, and almost certainly not the weakest link in your security chain.

It is a lot more likely that someone will steal passwords using social engineering, than by running known plaintext attacks. Even more so as you will probably not publish your code and your protocol on the internet, so an attacker would first have to reverse engineer your code. That's of course possible, but why do it if it is so much easier to send out a few thousand phishing mails or open a website (game cheats, porn, whatever...) and have people download a trojan, which they will happily do!

Anyway, there are a lot of possibilities to make that kind of attack a lot harder:

For example, your messages will usually be longer than one block. Thus, you can simply swap a byte between block 1 and 2 of your encoded message. Due to the properties of block algorithms, this will turn both block 1 and 2 into complete garbage.

Of course, if the attacker knows about that, he can in general simply do the same (and will of course!).

However, nothing prevents you from using a pseudorandom swap location. This location can be derived from some bits of the key or negotiated during authentication, whatever. It doesn't even have to be a very clever scheme.
You could also swap a byte between every two adjacent blocks, or the first and last block of a message. There goes... you have a kind of all-or-nothing scheme.

If the attacker wants to decode your message, he can of course still do that trivially (after figuring out your scheme). However, he now has to decode a dozen blocks to verify one key (instead of one), which means he has to use a lot more resources. To you however, swapping a few bytes is practically a no-op.

Similarly, you can make someone's life a lot less enjoyable if you insert a random intialisation vector into your message. You could even add a "less random" trailing vector which is mostly random, but contains one offset byte.
The length of init+trail vector shall be constant, and the real message block is at a random offset in between, so it is hard to use a "known" header value as plaintext.

Sure enough, given enough zeal, time, and cpu, this is trivial to break as well. But do you really think someone will attempt to do that when there are so many ways that are a lot easier and cheaper? :)