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...:)