svn commit: r238118 - head/lib/libc/gen

[Robert Watson]

On Tue, 24 Jul 2012, David Schultz wrote:

> On Wed, Jul 04, 2012, Doug Barton wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 07/04/2012 13:32, Andrey Chernov wrote:
>>> 1) /dev/urandom may not exist in jails/sandboxes
>>
>> That would be a pretty serious configuration error.
>
> Yes -- but the scary part is that arc4random() is not fail-safe at all.  If 
> /dev/random isn't there, you just silently get predictable "randomness". 
> If you needed that randomness for cryptographic purposes you're out of luck; 
> you might as well have used rot13.  Using the sysctl doesn't fix the failure 
> mode (in fact, as I recall the sysctl dubiously never reports failure even 
> if there is no entropy), but there's a narrower set of circumstances under 
> which the sysctl can fail.

Probably the most important thing for us to do is to make it clear which 
sources of randomness are appropriate for use in cryptography, and then 
propagate information to the downstream APIs as needed.  Given its chequered 
past, it's clear that srandomdev() on FreeBSD is not appropriate for use in 
generating keys -- programmers should prefer the OpenSSL APIs.  Currently, 
programmers are directed to arc4random(3) by random(3), but I'm actually not 
sure that is the right advice.  I'm of the (possibly debateable) view that no 
randomness initialisation routine that can't return a failure is appropriate 
for cryptographic purposes -- if generating a key and /dev/random can't be 
found, or only the kernel arc4random bits are available but they aren't known 
to be good for key generation, then key generation should fail.

Robert