lkml.org 
[lkml]   [2004]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Using compression before encryption in device-mapper
Date
Thank you for your comments.

Le Mercredi 14 Avril 2004 16:39, Grzegorz Kulewski a écrit :
> I think that not only compression should be moved to fs layer but
> possibly encryption also.
This is way easier IMHO, and totally preserves from the burden of meta-data
versus plain-data encryption. However there is one big drawback: you benefit
from encryption only when using the file-system for which you have such a
plugin (for example, you can _not_ do a RAID5 array over encrypted disks).
I believe this is too much of a drawback, put perhaps I am wrong.
>
> How?
> In Reiser4 there are plugins. [...]
> In order to protect guessing the key from decrypting possibly-well-known
> values in superblock and other metadata (cuch as fs size and signature) we
> could probably place random numbers before them and xor each 4 bytes with
> last 4 bytes before encryption (or use any other hash function).
This is the idea I have in mind, but with a little more sophisticated scheme
(see my reply to Paulo Marques): basically the sole purpose to "compress" is
to improve the per-bit entropy, and you can mix this with adequately
inserting random bytes before your data according to your compression
algorithm.

>
> Why?
> Because in dm approach you are encrypting entire blocks at once and in fs
> approach you are encrypting only needed parts. [...]
> So we can have situation that in one block there is 2 or 3 or
> maybe more files (or parts) encrypted using different keys and hashes and
> that these files reside at different offsets in that block. I think that
> this is easier to implement and protects better.
Actually I would have used the counter-argument to prove your point ;)
Let me explain : I believe (but I am no cryptographer) that it is a very
unwise idea to encrypt both data and meta-data at the same time. I prefer
extracting all meta-data, possibly encrypting them somewhere, and encrypt
data independently. This is basically because you can easily gain information
on meta-data (but not so easily on data themselves). This is the reason why
encrypting at the file-system level (where you encipher the content of files)
is better than at the device level (where you also encrypt meta-data; this is
however what I plan to do).

To follow your example, I would even prefer the offsets of the 2 or 3 files be
public rather than having them encrypted and let the attacker know that the
first 8 bytes of my sector encodes for offsets for 2 files, each of which
being less than 4096 (thus having many 0 bits inside it) : this might
tremendously help him reduce his search space.

But I do agree that encrypting at the file-system level might be a better
approach. However I believe this raises two issues:
1) you may want to also encipher the meta-data itself. A basic way to do this
would be to additionnaly use dm-crypt.
2) you can only profit from encryption with the file-system it has been
implemented for.

I personally have no political stance on wether developping a Reiser4-only
compression+encryption plugin would be unwise. I just loosily believe that it
is always better to support several FSes. Unless, of course, if this is
doomed to failed, which is the question I would like to answer before working
further on it.

What to you think ?

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/

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