On Mon, Apr 02, 2001 at 05:26:10PM -0700, Bill Stewart wrote:
> There's been a *lot* of discussion on various lists about
> best ways to implement /dev/random and /dev/urandom,
> and how to adapt principles from systems like Yarrow to
> improve the security of either or both of them.

Well, I may not have chosen the best possible alternative. But I have
taken principles from Yarrow and adapted them to this situation.

> I'm not especially convinced of the value of doing something
> "faster and more secure" than /dev/urandom -
> if you're trying to go faster, you've got a lot of work to do
> to demonstrate that your approach is also more secure,
> and if you're trying to go for more secure,
> you've got a lot of work to do to make the thing go faster --
> and if you succeed at these, the folks who run /dev/urandom
> may want to include your code.

Well, they're welcome to include it, but I don't know if they'll want to.
For one thing, it contains crypto code, and for another, it works just
fine as a userland daemon.

But: Yarrow is faster and more secure than /dev/urandom. The basic reason
is because they use a stream cipher rather than iterated SHA, and they
accept entropy in globs instead of dribbles. Both of which I do. They
also go to some trouble to make sure that their entropy estimation is good,
which I don't. I trust /dev/random.

If you want to look at the code, it's at
http://www.math.mcgill.ca/archibal/crypto/crandom.html

I think the code needs to be examined some more before it gets used too
much, but it does work. Crude tests place it about six times as fast as
/dev/urandom.

> If you want something "faster than /dev/random,
> but slower and more secure than /dev/urandom",
> there's more space to play with. For that case,
> I'd go with an approach like the following:
> - use a subroutine library running in the application's memory space
> (e.g. it needs a set of data per-process.)
> - if you're worried about paging security, remember that your
> improved-randomness library will get paged along with the
> application,
> which basically makes it the application designer's problem.

Why do you prefer it as a library, rather than a userland daemon? These
seem like good reasons to make it a single daemon that you can write
carefully.

> - pick a good random seed using /dev/random or more paranoid methods,
> like having the user input some data in addition to /dev/random.
> - use the seed to drive an PRNG, such as RC4-128,
> which you XOR with /dev/urandom.

I do exactly this.

> - optionally, make sure some other application is also using /dev/urandom.
> That has the advantage that it's not much slower (because RC4 is fast),
> but it's not less secure (because you're XORing with /dev/urandom).

If you use /dev/urandom by XORing it in, you open yourself up to the
possibility of a state compromise extension attack. If you periodically
use /dev/random to reseed (when you get 128, or to be conservative, 256
bits out of it) you can recover from state compromises.

Andrew

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]