Re: DIGEST-MD5 and {nonce,cnonce}

[Booker Bense <bbense@networking.stanford.edu>]

On Mon, 25 Oct 1999, Mihai Ibanescu wrote:

> On Mon, 25 Oct 1999, Kurt D. Zeilenga wrote:
> 
> > 
> > As noted by others, gettimeofday is not a good source of entropy.
> > 
> > I suggest that we implement routine in -llutil that uses appropriate
> > mechanisms (as detected through auto configuration) that return
> > the desired about of entropy.
> > 
> > 	int lutil_entropy( char *buf, int nbtyes )
> > 	/* returns nbytes of entropy in buf.  buf must be large
> > 	 * enough to hold nbtytes of data.  lutil_entropy returns
> > 	 * non-zero if unable to fulfill request.
> > 	 */
> > 
> > I would recommend we look at other codes and "borrow" from them
> > as appropriate.
> 
> 	Okay, I already have seen propositions on some options
> (/dev/random, which seems the most reliable, 

- Good. I seem to recall that /dev/random on linux uses disk access
timing which is acceptable. 

> and a PRNG started with a
> seed derived from gettimeofday,

- This is not good. If you were using Blub, Blub, Schum it would
be okay, but you need a better seed. And since the seed is roughly
the size of what you want to get, you might as well just get the 
seed and be done with it.   

> all of them hashed with MD5 or something
> like that). Any other alternatives?

- I looked in the ssh code. The file is randoms.c. It should
be okay on unix, most of what's in there won't work too well
on a PC. It uses the standard trick of accumalating the
output of a bunch of unix commands along with some time
info and MD5ing the whole mess. 

> 	I'd like to implement it. 
> 

- Whatever you implement, a very quick first test is to output
a 10k of data or so and see if gzip can compress it. If it 
can be compressed, it's not random. 

- Booker C. Bense