Re: Will I need to re-format my partition for using the compression plugin?

[Gregory Maxwell <gmaxwell@gmail.com>]

On 9/22/05, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> 1) RSA is useless for this - you really need a symmetric block cipher of some
> sort.  Almost all block ciphers are best used with maximum-entropy input - if
> the attacker can lop out a large part of the keyspace, a brute force attack
> becomes a lot easier.  This is somewhat related to the concept of "Hamming
> Distance". If the attacker tries a brute force attack, and the first 8 bytes of
> the output look like valid HTML, or English text, or anything else
> recognizable, he's almost certainly found found the correct key.  On the other
> hand, well-compressed data has very high entropy - as a result, it becomes
> harder to tell if a correct key has been found.  If it's English text, but
> 3 of the first 8 bytes have the high bit set, it's probably not a correct key.
> If it's compressed, 3 flipped bits in the first 8 bytes will probably still
> represent a valid compressed stream - just of something else wildly different.

It would normally seem silly to use RSA for disk encryption... but
there might be applications, although you'd still never use RSA
directly on user controlled data.  For example, RSA could be used on a
multi user server to append mail to a mail file so that once written
the data is only accessible once the user logs on.  The reiser4 crypto
system will use the kernel keyring api, so it would be quite
reasonable to tie encryption to user accounts. 'write only' files and
'read only' files would be a simple logical extension, and would
require asymetric cryptography.

Although for most compression algorithms not all inputs are valid
outputs, so this may not work for you... It would be ideal (for disk
encryption) if it were not possible to tell if you have the right key
without decrypting an entire sector. This requires careful selection
in compression and chaining mode.  Alternatively, it may be possible
to develop a good large block cipher which while being much slower
than a single block of a small-block cipher, is faster for a disk
block.  For example, mercy is about 4x faster than AES on my system
but is still 16x slower for the smallest unit of decryption than AES.
Unfortunately mercy has security problems.

> 2) Even though most modern block ciphers are designed to be fast, it's still
> faster to apply a reasonably quick compression scheme to whomp 16K of data
> down to 5-6K and encrypt/decrypt 5-6k than it is to encrypt/decrypt 16K.

Depends on the compression mode and the cipher. A good AES
implementation is around the same speed as an aggressive gzip. In
general this is correct.