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