dfs@doe.carleton.ca (David F. Skoll) (06/18/91)
It occurred to me that the standard Unix 'compress' utility would make a good encryption tool, used as follows: - Compress your text, using "compress" - Strip out any headers or "magic numbers" from the .Z file - Exclusive-or each character of the file with successive characters from a password, preferably 8 to 10 characters long. (In fact, if you use two passwords whose lengths are relatively prime and are "well chosen", you can achieve a password whose effective length is the product of the lengths of the two original passwords, by cycling through successive characters of both passwords and exclusive-oring the original data with both characters.) Now, the "exclusive-or" technique is very poor if you just apply it to straight text, because it can be broken by guessing the length of the password key, lining the codetext up into columns and using letter frequencies as a guide to decryption. However, the compress utility tends to even out the frequencies of the characters, thus making this approach very difficult. Is there a catch? -- David F. Skoll
wayner@CS.Cornell.EDU (Peter Wayner) (06/18/91)
dfs@doe.carleton.ca (David F. Skoll) writes: >It occurred to me that the standard Unix 'compress' utility would make >a good encryption tool, used as follows: >- Compress your text, using "compress" >- Strip out any headers or "magic numbers" from the .Z file >- Exclusive-or each character of the file with successive characters >from a password, preferably 8 to 10 characters long. (In fact, if you >use two passwords whose lengths are relatively prime and are "well >chosen", you can achieve a password whose effective length is the >product of the lengths of the two original passwords, by cycling >through successive characters of both passwords and exclusive-oring >the original data with both characters.) >Now, the "exclusive-or" technique is very poor if you just apply it to >straight text, because it can be broken by guessing the length of the >password key, lining the codetext up into columns and using letter >frequencies as a guide to decryption. However, the compress utility >tends to even out the frequencies of the characters, thus making this >approach very difficult. >Is there a catch? No. Just read the cryptography literature before doing this if you are curious. People have been worrying about this problem for a long time. There is plenty of good analysis of the problem. One good book was written by Dorthy Denning but the others are quite good as well. I wrote a paper on one twist, in fact. It describes a way of making Huffman compression somewhat more difficult to decrypt. I'll send you a copy if you want, or you can find it in Cryptologia, April 1988. >-- >David F. Skoll -- Peter Wayner Department of Computer Science Cornell Univ. Ithaca, NY 14850 EMail:wayner@cs.cornell.edu Office: 607-255-9202 or 255-1008 Home: 116 Oak Ave, Ithaca, NY 14850 Phone: 607-277-6678
thom@sea.ieee.org (Thom Henderson) (06/20/91)
> It occurred to me that the standard Unix 'compress' utility would make > a good encryption tool, used as follows: Congratulations. You have just re-invented ARC password encryption. <grin> > Is there a catch? Hope not. --- Group 2.23 * Origin: ystem Enhancement Associates (107/517) -- Thom Henderson - Internet: thom@sea.ieee.org