Messages in this thread | | | From | Guillaume Lacôte <> | Subject | Re: Using compression before encryption in device-mapper | Date | Fri, 23 Apr 2004 17:16:53 +0200 |
| |
Feel free to ignore all of my reply; please note that I am not trying to "be right" or to "be wrong" but I still do not understand ... Thank you still for your time and pedagogy.
> Yeah, sure, the attacker has no idea what the plaintext of those > blocks is, but if they appear often enough, it has to be something > quite common. Something like, say, all ones or all zeros. Or like > one of those 48 common huffman encodings thereof. > [...] > So what! You end up with maybe three bits per zero (assuming all > zeros). Depending on the size of random data up front, they start > with bit 1, 2 or 3. Makes 3*2^3 or 24 possibilities. Same for all > ones, give a total of 48. Great, a dictionary attack is 48x slower > now! > [...] > Still, towards the end of all-ones or all-zeros, each byte will be > encoded with the same 1-3bit value. The point I fail to understand is the following : you know the enciphered value of these 1-3bits. But how can you know what is compressed-but-deciphered 1-3bit value ? Ok my text contains only 0s. OK these 0s appear to be "011" once encrypted. How do you launch your dictionnary attack ? You do _not_ (?) know what the 3bit deciphered code for "0" is. Or maybe you do ?
> [...] > In that case, what's your point. If the key is strong and the > encryption is strong (I sure hope, AES is), nothing short of brute > force can be successful. What are you protecting against? Maybe my "endless" story is absurd, but I am _not_ protecting against weak keys; I am trying to protected against weak _data_ , which is the basis for dictionnary attacks even in the case of perfectly random keys.
Thank you for having read till here, Guillaume.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |