[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: DIGEST-MD5 and {nonce,cnonce} (fwd)

---------- Forwarded message ----------
Date: Mon, 25 Oct 1999 18:11:09 +0200
From: Bastiaan Bakker <Bastiaan.Bakker@lifeline.nl>
To: Mihai Ibanescu <misa@necomm.ro>
Cc: openldap-devel@OpenLDAP.org
Subject: Re: DIGEST-MD5 and {nonce,cnonce}

Mihai Ibanescu wrote:

> On Mon, 25 Oct 1999, Bastiaan Bakker wrote:
> > Mihai Ibanescu wrote:
> >
[ stuff about generating random data deleted ]

> >
> > To be blunt: using gettimeofday to get SECURE random numbers is a really
> > BAD idea! Most operating systems have much better ways to get random numbers
> > (for example /dev/random). These specifically have been developed with
> > security in mind, so use them!
>         Yeah, but I am thinking in terms of portability. Is reading from
> /dev/random portable enough? AFAIK, linux supports it, but Solaris does
> not.
>         Maybe I shouldn't think of portability now, and just use
> /dev/random.

I hope you think of both! :-) . OpenLDAP is a multi platform effort, so keeping
things portable is desirable.  Unfortunately there isn't a standard for getting
secure random numbers.

I guess the best way to do that is to design a generic API for obtaining secure
random data (could be just a few calls) and then implement that API for the
platfoms you need first.  That should make it  easy for other people to add proper
implementations for other platforms.  (For really lame OSes you can always
fallback to the gettimeofday, accompanied by lots of warnings about the security

- There are a couple of examples to look at: 

PGP source : they use the timing of key presses to generate random
data, good but very slow. 

Cyrus sasl source : Uses /dev/random or /dev/audio and defaults to 
a REALLY BAD way to use time to get random data. 

Perl Module: Math-TrulyRandom-1.0 
	Uses a timing routine written by  Don Mitchell and Matt Blaze.
Matt Blaze is a highly regarded crypto expert. It uses signal and 
set jmp, if you combined it with the sasl code that might be a pretty
good all purpose routine. 

- BTW, while hashing[1] does not increase entrophy it's a pretty good
way to "extract" it from a larger source. i.e. if you have a struct
that has roughly 8 bits of entrophy, if you concatenate 8 of them and 
hash that you have a pretty good chance of getting 64 bits of
entrophy. The of course assumes that the 8 samples are independent. 
If you take the output of most Pseudo-Random number generators 
(i.e. drand48, rand, etc ) concat them and hash you don't get 
any more entrophy ( in fact you get alot less.... )

- Booker C. Bense 

[1] You must use a cryptographically secure hash such as MD5.