1993-05-21 - cypto + compression

Header Data

From: Stanton McCandlish <anton@hydra.unm.edu>
To: cypherpunks@toad.com
Message Hash: c58e4b98bf02a9b1db78e1bb1a9a2c478f044dc8e32cd27c07fb2ade2e654052
Message ID: <9305212100.AA18233@hydra.unm.edu>
Reply To: <9305200743.AA02030@netcom.netcom.com>
UTC Datetime: 1993-05-21 21:00:19 UTC
Raw Date: Fri, 21 May 93 14:00:19 PDT

Raw message

From: Stanton McCandlish <anton@hydra.unm.edu>
Date: Fri, 21 May 93 14:00:19 PDT
To: cypherpunks@toad.com
Subject: cypto + compression
In-Reply-To: <9305200743.AA02030@netcom.netcom.com>
Message-ID: <9305212100.AA18233@hydra.unm.edu>
MIME-Version: 1.0
Content-Type: text/plain


Just thought of something (I hope it gives someone a business idea, I have
plenty to spare at the moment.)

OK: compression, simplified, works (in several of its manifestations at least)
by replacing redunant parts with a single part that represents 1) what the
replaced parts are, and 2) how many there are.  Thus "feed" could be compressed
as "f!d" where ! = "2 e's".  I know, I know this is a terrible oversimplifica-
tion, but that's the juice of the fruit, no?

OK well if you encrypt a compressed file, there are bound to be lots more
new redundencies created in the encryption process (unless it is something
like ROT-13).  Why not compress this AGAIN, squeezing more space out of the
data?  Sure you can do this manually but things like DES are slow.  What I
am thinking is: have something like zip or compress that compresses, encrypts,
then recompresses, and repeats this process until it can compress no more.

Compression/extraction time will slow down, but for those that NEED heavy-
duty compression, big deal.  It shouldn't really be TOO bad, since this
almost 1/2-assed encryption need not be secure in any way, it could have
a very short key.  

Any ideas?  What is wrong with this idea? (something must be, or it would've
been done by now, I am guessing.)  I don't know the math, so I suspect I 
must've erred gravely somewhere.
-- 
Testes saxi solidi!  **********************   Podex opacus gravedinosus est!  
Stanton McCandlish,  SysOp:  Noise in the Void Data Center BBS
IndraNet: 369:1/1      FidoNet: 1:301/2      Internet: anton@hydra.unm.edu
Snail: 8020 Central SE #405, Albuquerque, New Mexico 87108 USA
Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1)
Vox phone:  +1-505-247-3402 (bps rate varies, depends on if you woke me up...:)





Thread