From: "Guillaume Lacôte" <Guillaume@Lacote.name>
To: Pascal Schmidt <der.eremit@email.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Using compression before encryption in device-mapper
Date: Wed, 14 Apr 2004 17:25:31 +0200 [thread overview]
Message-ID: <200404141725.31660.Guillaume@Lacote.name> (raw)
In-Reply-To: <E1BDluf-00007s-PB@localhost>
Le Mercredi 14 Avril 2004 17:02, Pascal Schmidt a écrit :
> On Wed, 14 Apr 2004 16:10:20 +0200, you wrote in linux.kernel:
> > Actually (see my reply to Timothy Miller) I really want to do
> > "compression" even if it does not reduce space: it is a matter of growing
> > the per-bit entropy rather than to gain space (see
> > http://jsam.sourceforge.net).
>
> How is the per-bit entropy higher when the same amount of data (and
> thus entropy on that data) is sometimes contained in *more* bits?
>
> I can see the argument if data is really compressed, because then more
> bits than would normally fit into, say, a sector, contribute to the
> entropy of the final sector.
You are perfectly right. If I recall correctly from Paul Li and Ming Vitanyi,
An Introduction to Kolmogorv Complexity, then the minimum length of an
encoding (e.g. a static two-pass Huffman encoding) is equal to the total
entropy of the text, or one more than that (this is also asymptotically equal
to the Kolmogorov complexity of the text). In particular the static encoding
can not be longer than the original text.
However I do _not_ want to have any form of meta-data, dictionnary, etc. Thus
I need to use dynamic encoding, were the huffman tree is dynamically updated
(both while compressing or while decompressing) as characters are
read/written. The problem is that the encoding "evolves" and in particular it
can be (and usually is) worse than the static encoding.
J. S. Vitter showed that the dynamic algorithm by Faller, Gallager and Knuth
can use twice more bytes plus one bit per byte than the optimal static
Huffman encoding. On the other hand J. S. Vitter discusses dynamic algorithm
that uses only one more bit per byte in the worst case when compared to the
static encoding.
You are right that in this very case, the per-bit entropy will be
(1 - 1/(1+1/8) ) ~ 12% lower than in the original text. The point is that this
case (which has nothing to do with the case where a text can be well
compressed or not, this is the worst _relative_ performance of dynamic versus
static encoding) does not happen "too often".
Note that I wish to prepend random bytes followed by the block of real text
before compressing and ciphering, so as to make the distribution of huffman
trees uniform. The ultimate goal being to let no other solution to an
attacker than to brute force test all possible keys. An indirect consequence
on this is that the probability of being in the "poor dynamic performance"
case does not depend on the data itself (but on the random drawing).
I hope that I made things clearer and that I didn't make any mistake (please
feel free to correct me).
Guillaume.
next prev parent reply other threads:[~2004-04-14 15:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1KykU-4VD-17@gated-at.bofh.it>
[not found] ` <1KPvh-26S-7@gated-at.bofh.it>
[not found] ` <1KSMw-4P1-13@gated-at.bofh.it>
[not found] ` <1KTfJ-5gK-25@gated-at.bofh.it>
2004-04-14 15:02 ` Pascal Schmidt
2004-04-14 15:25 ` Guillaume Lacôte [this message]
2004-04-14 19:29 ` Pascal Schmidt
2004-04-13 15:44 Guillaume Lacôte
2004-04-13 16:57 ` Timothy Miller
2004-04-14 6:48 ` Guillaume Lacôte
2004-04-13 17:45 ` Jörn Engel
2004-04-13 19:42 ` Ville Herva
2004-04-14 6:54 ` Guillaume Lacôte
2004-04-14 9:43 ` Jörn Engel
2004-04-14 10:02 ` Guillaume Lacôte
2004-04-14 11:25 ` Jörn Engel
2004-04-14 12:44 ` Paulo Marques
2004-04-14 13:34 ` Jörn Engel
2004-04-14 13:58 ` maccorin
2004-04-14 14:02 ` Guillaume Lacôte
2004-04-14 14:39 ` Grzegorz Kulewski
2004-04-14 15:07 ` Guillaume Lacôte
2004-04-14 16:14 ` Grzegorz Kulewski
2004-04-14 15:23 ` Paulo Marques
2004-04-14 15:32 ` Guillaume Lacôte
2004-04-14 17:25 ` Bill Davidsen
2004-04-15 9:28 ` Jörn Engel
2004-04-22 7:59 ` Guillaume Lacôte
2004-04-22 9:18 ` Jörn Engel
2004-04-22 10:20 ` Guillaume Lacôte
2004-04-22 12:15 ` Jörn Engel
2004-04-22 13:06 ` Guillaume Lacôte
2004-04-22 16:00 ` Jörn Engel
2004-04-23 15:16 ` Guillaume Lacôte
2004-04-23 16:57 ` Jörn Engel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200404141725.31660.Guillaume@Lacote.name \
--to=guillaume@lacote.name \
--cc=der.eremit@email.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®