Messages in this thread | | | From | Guillaume Lacôte <> | Subject | Re: Using compression before encryption in device-mapper | Date | Wed, 14 Apr 2004 17:07:03 +0200 |
| |
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/
| |