Talk:Unix directory structure: Difference between revisions
Jump to navigation
Jump to search
imported>Subpagination Bot m (Add {{subpages}} and remove checklist (details)) |
imported>Alexander Wiebel (→urandom and random: new section) |
||
| Line 1: | Line 1: | ||
{{subpages}} | {{subpages}} | ||
== urandom and random == | |||
Are Unix and Linux different in this case? My man page says the following: | |||
When read, the /dev/random device will only return random bytes | |||
within the estimated number of bits of noise in the entropy pool. /dev/random | |||
should be suitable for uses that need very high quality randomness such as one-time | |||
pad or key generation. When the entropy pool is empty, reads | |||
from /dev/random will block until additional environmental noise is gathered. | |||
A read from the /dev/urandom 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 non-classified literature, but it is | |||
theoretically possible that such an attack may exist. If this is a concern in | |||
your application, use /dev/random instead. | |||
--[[User:Alexander Wiebel|Alexander Wiebel]] 10:30, 7 February 2008 (CST) | |||
Revision as of 11:30, 7 February 2008
urandom and random
Are Unix and Linux different in this case? My man page says the following:
When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.
A read from the /dev/urandom 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 non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.
--Alexander Wiebel 10:30, 7 February 2008 (CST)