The perils of security tools

[Simon Josefsson]

Ben Laurie <ben at links.org> writes:

> Steven M. Bellovin wrote:
>> On Sat, 24 May 2008 20:29:51 +0100
>> Ben Laurie <ben at links.org> wrote:
>>
>>> Of course, we have now persuaded even the most stubborn OS that
>>> randomness matters, and most of them make it available, so perhaps
>>> this concern is moot.
>>>
>>> Though I would be interested to know how well they do it! I did
>>> have some input into the design for FreeBSD's, so I know it isn't
>>> completely awful, but how do other OSes stack up?
>>>
>> I believe that all open source Unix-like systems have /dev/random
>> and /dev/urandom; Solaris does as well.
>
> I meant: how good are the PRNGs underneath them?

For the linux kernel, there is a paper:

http://eprint.iacr.org/2006/086

Another important aspect is the semantics of the devices: None of the
/dev/*random devices are standardized anywhere (as far as I know).
There semantics can and do differ.  This is a larger practical problem.

For example, reading a lot of data from linux's /dev/urandom will
deplete the entropy pool in the kernel, which effectively makes reads
from /dev/random stall.  The two devices uses the same entropy pool.

I believe a much better approach would be if /dev/urandom was a fast and
secure PRNG, with perfect-forward-secrecy properties, and /dev/random
was a slow device with "real" entropy (whatever that means..) gathered
from the hardware.  The two devices would share little or no code.  The
/dev/urandom PRNG seed could be fed data from /dev/random from time to
time, or from other sources (like kernel task switching timings).  I
believe designs like this have been proposed from time to time, but
there hasn't been any uptake.

/Simon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com