From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 12-OCT-1993 15:28:51.88 To: EVERHART CC: Subj: anybody know about this? Date: Tue, 12 Oct 1993 12:30:53 GMT From: "Glenn C. Everhart" To: INFOVAX@arisia.gce.com Message-Id: <931012123053.a2@arisia.gce.com> Subject: anybody know about this? Folks - Some time ago I wanted to come up with a way to keep random folks out of files they shouldn't have to do with, and tried to do a little cascade with CRCs (seeing that this is easy on a VAX.) The basic idea was to take a key phrase (variable length) and use a polynomial pulled out of the air to compute crc(key, poly) = MK I then took some bits of the crc(key,poly) and formed a starting polynomial, and took some other bits and formed an interval between polynomials, so that I had a bunch of polynomials of form WP= a * shifted up a few bits + + const and proceeded to generate a nice LONG string from this, using a=1,2,3,4,... and then for each A computing WK=CRC(key, WP) so that I had a very long string of bits that I could then XOR the original text with. (I added a couple fixed XORs that were other polynomial CRCs of the key and multiples of block number, but I suspect these would by themselves be pretty trivial to invert.) I suspect that if instead of a CRC function I were to use some "authentication" function, the result would be stronger; such a function would be of form f(text, key) instead of crc(key, poly), so the thing formally ought to be doable. However, in my experimenting I found that just using CRC produces a result that doesn't compress at all well (in fact it's really terrible) with any of the PD compression packages I've tried (zip, lharc, compress, sq,...), and I don't see any simple way to invert it. (Also, CRC is simpler on a VAX :-) ). I only think about these things occasionally, though, and am wondering if anyone in the group with more info can see that the scheme is vulnerable to someone breaking in anyhow? Once you generate the bits, doing the XORs is blindingly fast, so this makes a pretty good way to keep data private that should be. (Generating the CRCs is of course pretty slow on some machines.) I suspect the method won't keep real cryptographers out of the data for long, but does anyone have a feel for whether there are backdoors this sort of thing leaves, and perhaps how long the xor string might have to be before it starts really getting useful or weak? The CRCs I used are of course only 32 bits long, so there's got to be a limit somewhere. I just can't see it. OTOH, if nobody else sees any gaping holes, I'd suppose that suggests J. Random System Cracker wouldn't either... Glenn