Newsgroups: sci.crypt
Path: msuinfo!caen!umeecs!umn.edu!cs.umn.edu!lynx!triton.unm.edu!ee5391aa
From: ee5391aa@triton.unm.edu (Duke McMullan n5gax)
Subject: Re: Encrypting with MZT sequences?
Message-ID: <j3vg2zq@lynx.unm.edu>
Date: Mon, 27 Jan 92 06:37:10 GMT
Organization: University of New Mexico, Albuquerque
References: <1992Jan24.054440.22882rcain@netcom.COM>
Lines: 66

In article <1992Jan24.054440.22882rcain@netcom.COM> rcain@netcom.COM
(Robert Cain) writes:

>Recently there has been a new class of random sequence generators invented
>with ridiculously long periods and apparantly excellent randomness.  It is
>fast, involving fairly simple arithmetic and real big state variables
>which could be used as keys.  The reference is:

>Marsaglia, Zaman, and Tsang.  "Toward a Universal Random Number Genderator."
>Statistics & Probability Letters 8 (1990) 35-39. North Holland (Elsevier)

>I would appreciate any comment or analysis by professionals in the field
>of cryptography regarding the use of these sequences to xor with plain
>text to encrypt before I spend any time implementing it.

Unfortunately, the state variables (# words of memory used by the generator)
aren't very big at all.  (This is one of the _advantages_ of the MZT gener-
ators, and it has nothing to do with cryptography.)  Additionally, the output
words of the generators _are_ the state variables, in sequence.

That means, if you use a simple XOR of your plaintext bitstream with the
generator bitstream, that you can deduce the state of the generator by a
judicious guess at a relatively small portion of the message, compromising
the entire message in one swell foop.

That's not so say that the MZT generators are of no cryptographic value --
but you need to insure that the generator's state information isn't com-
promised by guessing some of the output bitstream.

There are some pretty straightforward ways of doing this.  For instance, you
can take more than one generator, and combine the outputs _nonlinearly_ (mul-
tiply them, for instance), and get your output bitstream from this.  A prob-
lem here is that the bit statistics on a pair of multiplied bitstreams start
to get a little funny.  There are ways of compensating for this, but I don't
have much knowledge of them, nor of references.  (Didn't Knuth have something
to say about this problem?  Anyone?)

It might prove sufficient to drop a couple each of high- and low-order bits
of the product. I seem to recall a technique like this somewhere . . . .

I suppose that if you took four or five different MZT generators, and perhaps
threw in a LFSR or two, XORed all of them, and then XORed with the plaintext
bitstream, you might have a cryptoalgorithm that's damn hard to crack, but all
those XORs are linear, and that bothers me. Too, the key would be an awful lot
of state (initialization states of all the generators).  Still, Khufu uses a
lot of info in its key, and Merkle presents good arguments that it isn't much
of a problem.

I don't doubt that the MZT generators will prove useful in cryptography, but
they certainly don't amount to a quick-and-easy, almost-impossible-to-break
bitstream generator.

Here's a thought, f'rinstance.  Use an algorithm widely thought to be pretty
strong, such as Khufu or DES.  Use it, say, three times on each block of
plaintext.  In between the first and second layers, XOR with an MZT bitstream.
This requires a cryptoalgorithm of considerable strength in addition to MZT,
but produces a deeply-buried and potent influence by the MZT state on the
output ciphertext.  Certainly, it won't make the cryptanalyst's job any easier.


						d


-- 
	    The very, very best hiking is found . . . underground!
  Duke McMullan n5gax nss13429r phon505-255-4642 ee5391aa@triton.cirt.unm.edu
