Re: Using compression before encryption in device-mapper

[Guillaume Lacôte]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/