Re: insufficient entropy for rnd

[Daniel Carosone <dan%geek.com.au@localhost>]

On Mon, Aug 11, 2003 at 08:19:00PM +0200, Rumi Szabolcs wrote:
> Hello!
> 
> I've got a server running NetBSD/i386 which is getting a
> relatively low load. I'm running sendmail on it using SMTP
> authentication via Cyrus SASL, which seems to use /dev/random.
> When a mail gets relayed in such an authenticated manner,
> sendmail often drops the connection with a timeout during
> the authentication process which I believe is due to insufficient
> randomness coming out of /dev/random so that read is blocking
> so long that the SMTP connection gets timed out. When I make
> a "find / -name blahblah" that puts some load on the filesystem
> so that more entropy is gathered by rnd, this instantly revives
> sendmail and the authentication succeeds...
> 
> Maybe Cyrus SASL (mine is 2.1.12 from pkgsrc) could be compiled
> to use /dev/urandom instead, but for me this sounds more like
> a workaround than a solution at least for a crypto purpose.

It has to use urandom, for exactly the reason you describe. Stuff
opening /dev/random has to be prepared to wait (arbitrary) amounts
of time.

A core part of the problem you're experiencing here is that the
entropy estimation code (that causes random to block) is
ultra-ultra-conservative, to the point of probably being meaningless.

But in any case, you should not be opening the blocking device for
a network service you want to be generally available. Note that
there's a trivial DOS attack against the service otherwise.

Below are some more tips you can use to stir more stuff in the
pool, and make the pool bigger if you like. These will give you
some more confidence that the non-blocking reads from urandom won't
be poor-quality.

> Wouldn't it be better to figure out more entropy sources
> for a better feed of rnd? 

You should do both.

Since this machine is probably busy on the network, you should
consider enabling the network interfaces as entropy sources.

This is done with rndctl(8).

> I also wonder how big the entropy
> gathering pool is and how long it "caches" the entropy
> that has been gathered.

By default it is 128 words (x 32 bits). It can be made bigger, for
example I have:

options         RND_POOLWORDS=512

(note this MUST be a power of two)

As noted above, the estimation mechanism of how much "entropy" is
presently in the pool is very conservative, and favours draining
- so its easy for the pool to be "emptied". There is nothing
whatsoever different about what happens when the estimator is
"empty", other than /dev/random blocking.

Having a larger pool probably helps fudge the estimator more than
it really helps the "quality" of the randomness produced.

In any case, you want more inputs.  For unattended servers with
access to environmental vibration or airflow, an optical mouse can
be a useful and cheap entropy generator.  Hang it in an airstream
with a piece of paper.

On NetBSD/i386 (and several other ports) the timing information
added to the pool for the various events is based on the cpu cycle
counter, so its very high precision and therefore harder to predict.
Anything hardware-interrupt-driven is likely an acceptable source,
especially when there are several, but network devices are off -
again as a conservative default.

--
Dan.