Beware of /dev/random on Mac OS X

[Peter Hendrickson]

It's a /dev/urandom which has been labeled "/dev/random".  It claims
to be a Yarrow implementation so is presumably only 160 bits strong.
(See http://www.counterpane.com/yarrow-notes.html.)

>From http://www.hmug.org/man/4/urandom.html:
> /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom
> will produce lower quality output if the entropy pool drains, while
> /dev/random will prefer to block and wait for additional entropy to
> be collected.  With Yarrow, this choice and distinction is not
> necessary, and the two devices behave identically. You may use
> either.

As I'm sure everybody here knows, /dev/random on every other OS blocks
until it has enough entropy available because that is what /dev/random
is.  The design goal is that it is as strong as the number of bits
read from it.

Here are the NetBSD and Linux man pages for comparison:
http://netbsd.gw.com/cgi-bin/man-cgi?rnd+4+NetBSD-current
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=man&fname=/usr/share/catman/man4/random.4.html

>From the Apple man page, it appears they are aware of the problem but
consider it to be unimportant:
> Paranoid programmers can counter-act this risk somewhat by collecting
> entropy of their choice (e.g. from keystroke or mouse timings) and
> seeding it into random directly before obtaining important random
> numbers.

This workaround doesn't cut it for three reasons.

First, the entropy pool in Yarrow is only 160 bits.  From Section 6
"Open Questions and Plans for the Future" of the Yarrow paper
referenced above:
> Yarrow-160, our current construction, is limited to at most 160 bits
> of security by the size of its entropy accumulation pools.

If the program needs more than 160 bits, it can seed it with more than
that amount of entropy.  (Strictly, it could seed it with 160 bits,
read it, seed it, read it...., but this isn't mentioned on the man
page.)

Second, the seeding process needs to guarantee that no other process
drains the entropy pool before it can read it.  This is not possible.

Three, the great idea behind /dev/random is that the program doesn't
have to manage entropy itself.  This is a good thing because the
kernel has access to entropic bits which the process doesn't.  Also,
each environment varies so good sources of entropy on one machine may
not be so good on another.  /dev/random permits the implementation of
good portable crypto - except to OS X.

Apple apparently only accepts bug reports from members of the "Apple
Developers Connection".  If any such members are on this list, it
might be a good idea to submit a report:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa

Apple's inability to provide a real /dev/random is inexplicable given
that free implementations have been available for years.  Even if
Apple feels uncomfortable with GPL'd code, there's BSD licensed code
as well.

Peter

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