mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.


  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®