Date: Wed, 14 Apr 2004 09:58:33 -0400
From: maccorin@cfl.rr.com
To: linux-kernel@vger.kernel.org
Subject: Re: Using compression before encryption in device-mapper
Message-ID: <20040414135833.GA30062@lappy>
Mail-Followup-To: linux-kernel@vger.kernel.org
References: <200404131744.40098.Guillaume@Lacote.name> <200404140854.56387.Guillaume@Lacote.name> <20040414094334.GA25975@wohnheim.fh-wedel.de> <200404141202.07021.Guillaume@Lacote.name> <407D3231.2080605@grupopie.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <407D3231.2080605@grupopie.com>
User-Agent: Mutt/1.4.2i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1004
Lines: 23

On Wed, Apr 14, 2004 at 01:44:33PM +0100, Paulo Marques wrote:
> Guillaume Lac?te wrote:
> 
> >>>Oops ! I thought it was possible to guarantee with the Huffman encoding
> >>>(which is more basic than Lempev-Zif) that the compressed data use no
> >>>more than 1 bit for every byte (i.e. 12,5% more space).
> 
> WTF??
> 
> Zlib gives a maximum increase of 0.1%  + 12 bytes (from the zlib manual), 
> which for a 512 block will be a 2.4% guaranteed increase.
> 
> I think that zlib already does the "if this is bigger than original, just 
> mark the block type as uncompressed" algorithm internally, so the increase 
> is minimal in the worst case.

It is my impression that meta-data is exactly what he wants to avoid as it would
provide known data for crackers
-
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/