// COMPLETE THREAD

Re: Strong PRNGs

2 expanded posts ยท every known parent and child

NODE d4449090Re: Strong PRNGs
>Message-Id: <9310061432.AA16969@snark.lehman.com>
>Subject: Re: Strong PRNGs 
>Date: Wed, 06 Oct 1993 10:32:26 -0400
>From: "Perry E. Metzger" <pmetzger@lehman.com>



>Carl Ellison says:
>> I  can think of two:
>> 
>> 1.	a long-period PRNG (like subtract-with-carry) feeding a
>> 	cryptographically strong hash function (perhaps triple-DES
>> 	in ECB  mode with both key nad input taken from the PRNG
>> 	and output becoming the new PRNG output);
>
>What would the point of using this for a one time pad be, though? Why
>not just use triple-DES and be done with the bulk and complexity?

I'm not advocating it as a replacement for triple-DES.  I was answering
a question.

I have many uses for random numbers and none of them is XOR encryption.

However, I can even see a point for using this for XOR encryption [I prefer
not to call anything using a PRNG One-Time-Pad].  I can see two points,
even:

1.	You might have traffic which operates in very high speed bursts
	(faster than your triple-DES can go) but for which the average
	throughput is well within the speed of your triple-DES.  So, you
	keep your PRNG/DES grinding and building a buffer of bytes to be
	used, then you use them at high speed during the burst.


2.	Knuth's Algorithm M (from someone else) mixes two PRNG streams and
	the result is stronger than either of the two sources.  I haven't
	read the paper he references, so I don't know how much stronger,
	but if there's any strength to be gained, someone might want to use
	it.

 - Carl
NODE 6441db0bRe: Strong PRNGs
>Carl Ellison says:
> However, I can even see a point for using this for XOR encryption [I prefer
> not to call anything using a PRNG One-Time-Pad].  I can see two points,
> even:

Another point: it raises the possibility of an interesting loophole
in the ITAR.  Cryptographic hash functions are exportable, as "systems
for authentication", or something to that effect.  A random-number
generator based on a hash function should be exportable.  After all,
as you say, 
> I have many uses for random numbers and none of them is XOR encryption.

But such an RNG *could* be used for encryption.  If you package and
market it as such, you're asking for trouble.  But packaged as a
library routine in a simulation library?  It's not a fast PRNG, but
it should be pretty good statistically.

   Eli   ebrandt@jarthur.claremont.edu