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


Guillaume Lacôte wrote:
> Hi,
>
> I hope this is the right place to post this message; I tried to keep it small.
> Basically I really would like to implement compression at the dm level,
> despite all of the problems. The reason for this is that reducing redundancy
> through compression tremendously reduces the possibilities of success for an
> attacker. I had implemented this idea in a java archiver (
> http://jsam.sourceforge.net ).
>
> Although I am not a good kernel hacker, I have spent some time reading
> compressed-loop.c, loop-aes, dm-crypt.c, and various threads from lkml
> including http://www.uwsg.iu.edu/hypermail/linux/kernel/0402.2/0035.html
> Thus I would appreciate if you could answer the following questions regarding
> the implementation of a "dm-compress" dm personality.
>
[snip]

I have a suggestion. If you're compressing only for the sake of
obfuscation, then don't really try to save any space. Use a fast
compression algorithm which doesn't necessarily do a great job.

When you're going to write, compress the block. If it gets smaller,
fine. Store it in the same space it would have required even if it were
uncompressed. If the block gets bigger, then store it uncompressed.
Whether or not the block could be compressed would be stored in metadata
(in the inode, I guess).

-
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.065 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site