lkml.org 
[lkml]   [2004]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Using compression before encryption in device-mapper
On Fri, 23 April 2004 17:16:53 +0200, Guillaume Lacôte wrote:
>
> 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.

No need to mention this. I'll stop whenever I feel like it.

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

I know the encrypted text and I know it is common, so the uncompressed
decrypted text is likely 0x00,... Now, what may the compressed
decyphered text be? It could be:
000,000,...
001,001,...
010,010,...
011,011,...
.
.
.

Actually, the 000 and 111 cases don't even have three variants
depending on when they start, so the 48 above comes down to 40. And
since I honestly don't case whether it was 0x00 or 0xff, that was
encrypted to 001,001,..., it even comes down to 20.

You are right, I don't know which one of those 20 it is, but I am
quite sure it is one of them.

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

Show me the paper. Since when is AES weak against known plaintext
attacks?

Jörn

--
The grand essentials of happiness are: something to do, something to
love, and something to hope for.
-- Allan K. Chalmers
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.094 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site