Considerations about /dev/urandom in the documentation

[polettix]

Hi! I stumbled upon article Myths about /dev/urandom and thought it might be interesting to review this module's documentation in its light - especially for what the classification of /dev/urandom as a Weak source is concerned, and its preference over /dev/random.

The updated man page of /dev/random seems to acknowledge this too:

The /dev/random interface is considered a legacy interface, and
/dev/urandom is preferred and sufficient in all use cases, with
the exception of applications which require randomness during
early boot time; for these applications, getrandom(2) must be
used instead, because it will block until the entropy pool is
initialized.

[danaj]

Thanks!

I'll review it. I completely agree, and always have. There is a brief though ambiguous and indirect discussion about it in the documentation. Weak is certainly a dubious description.

At the time I created it (March 2013), I was getting a lot of pushback about /dev/urandom, and at that time the manual page you reference had this text:

A read from the \fI/dev/urandom\fP device will not block
waiting for more entropy.
As a result, if there is not sufficient entropy in the
entropy pool, the returned values are theoretically vulnerable to a
cryptographic attack on the algorithms used by the driver.
Knowledge of how to do this is not available in the current unclassified
literature, but it is theoretically possible that such an attack may
exist.
If this is a concern in your application, use \fI/dev/random\fP
instead.

Which does justify "Weak" as a description if you ignore the code.

I'll add that in Math::Prime::Util, the order is /dev/urandom first, as that's better for most purposes.