Re: compression vs encryption

[bill.stewart@pobox.com]

At 06:15 PM 8/6/98 +0800, Bernardo B. Terrado wrote:
>What's the difference between compression and encryption?
>Correct me if I'm wrong,  in compression we lose something, like in 
>image compression and audio compression,  but in encryption, we don't. 

Compression makes stuff smaller; encryption keeps stuff private.

Compression works by not sending data you don't need -
there are lossless compression systems, like simple run-length encoding
and more complex systems like Huffman and Lempel-Ziv,
which build abbreviations for common strings, 
and lossy compression systems like some JPEG and MPEG modes
and most voice compression systems which discard information
that doesn't have much effect on the user's perception of the image/sound.

You can find books on compression techniques, and can find
compression discussed in general books on algorithms.
For lossless compression, you can get by knowing simple math,
like probability and statistics, though it helps to know
about polynomials and modular arithmetic and such. For image compression, 
it helps to know about discrete cosine transforms and that sort of math.  
Audio compression includes simple techniques like
Adaptive Differential Pulse-Code Modulation, for which a little
calculus is helpful but not too critical, and complex techniques
using frequency spaces, Fourier transforms, and various models
of the human vocal tract, for which you need more math.

RLE is simple, and can work well or badly depending on the data.
For each set of repeated characters, it sends the character and count.
If the data usually has long runs of values, e.g. lots of black
and lots of white, it wins; if most values happen once in a row, it loses.
With Huffman coding, the input strings are usually the same length,
e.g. single letters, and the output strings are variable length,
with short output strings used for more frequently used inputs,
and longer output strings used for less frequently used inputs;
the more you know about the statistics of the input stream,
and the more unbalanced the statistics are, the smaller the output.
With Lempel-Ziv, the output strings are almost-constant length
indexes into a table of input strings which is built dynamically,
so the first time the compressor sees a string "ab", it creates a
table entry and sends the entries for "a" and "b", and the next time 
it sees "ab", it sends the code for "ab" (and also creates the 
code for "abc", if "c" is the next entry....)

There are also books about encryption.
Bruce Schneier's book "Applied Cryptography" is popular and good.

Most encryption systems compress their plaintext before encrypting,
partly because it's usually faster, partly because you can't
make encrypted text smaller by compressing it, and partly because
it can be more resistant to attacks like known-plaintext and chosen-plaintext.

>One sure protection againts evil hackers is encryption (?), but what if 
>that evil hacker deletes the ciphertext file and the plain text file (that
>is assuming the evil hacker just deletes every file he wants to delete).
>---at least he/she didn't read/saw the file.

If evil people can get on your system, you lose.
Encryption is part of protecting a system, but not enough.
Encrypting your disk drives helps reduce the risk if
they steal your computer (when police steal computers,
they use fancy words like "subpoena" and "confiscate", 
but it's the same thing :-).  Encrypting your email
means that evil people can't read it when it's in transit.
But if they can break in to your machine because you're using 
Windows or a badly-configured Unix system,
they may be able to read your mail or files before you encrypt them,
or read your incoming mail after you decrypt it,
or replace your encryption program with something that
also lets them decrypt the mail, and you still lose.
				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639