Re: Beware of /dev/random on Mac OS X

2003-09-02 Thread Michael Shields
In message [EMAIL PROTECTED],
Peter Hendrickson [EMAIL PROTECTED] wrote:
 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

Membership in ADC is available in both free and paid versions.  You
can set up an account for the free version at:
http://connect.apple.com/
-- 
Shields.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Beware of /dev/random on Mac OS X

2003-08-29 Thread 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=linuxdb=manfname=/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 [EMAIL PROTECTED]


Re: Beware of /dev/random on Mac OS X

2003-08-29 Thread Tim Dierks
At 05:01 PM 8/28/2003, Peter Hendrickson wrote:
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.)
Can anyone who believes that only having 160 bits of entropy available is 
an interesting weakness tell me why? I'm currently of the belief that 
there's far too much entropy paranoia out there. Barring disclosure of the 
entropy pool, I'm not aware of any plausible attack that could occur if I 
(for example) generate a bunch of keys from a single 160-bit entropy seed, 
given that I believe a 160-bit value to be invulnerable to brute force for 
quite a long time. I can't imagine any situation in which the lack of 
reseeding is going to be the weakness in this scenario, but maybe I'm 
insufficiently imaginative.

 - Tim



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]