Talk:Unix directory structure

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)

I SSH'd into the Solaris 10 box we have at work, and here's its man page on urandom ('man urandom'):

DESCRIPTION
     The /dev/random and /dev/urandom  files  are  special  files
     that  are  a source for random bytes generated by the kernel
     random  number  generator  device.   The   /dev/random   and
     /dev/urandom  files  are suitable for applications requiring
     high quality random numbers for cryptographic purposes.

     The generator device produces random numbers from  data  and
     devices available to the kernel and estimates  the amount of
     randomness (or "entropy") collected from these sources.  The
     entropy  level  determines the amount of high quality random
     numbers that are produced at a given time.

     Applications retrieve random bytes by reading /dev/random or
     /dev/urandom. The /dev/random interface returns random bytes
     only when sufficient amount of entropy has  been  collected.
     If  there  is  no entropy to produce the requested number of
     bytes,  /dev/random  blocks  until  more  entropy   can   be
     obtained.  Non-blocking  I/O mode can be used to disable the
     blocking behavior. The /dev/random interface  also  supports
     poll(2). Note that using poll(2) will not increase the speed
     at which random numbers can be read.

     Bytes retrieved from /dev/random provide the highest quality
     random numbers produced by the generator, and can be used to
     generate  long  term  keys  and  other  high  value   keying
     material.

     The  /dev/urandom interface returns bytes regardless of  the
     amount  of  entropy  available.  It does not block on a read
     request due to lack of entropy. While bytes produced by  the
     /dev/urandom  interface are of lower quality than bytes pro-
     duced by /dev/random, they are nonetheless suitable for less
     demanding  and shorter term cryptographic uses such as short
     term session keys, paddings, and challenge strings.

     Data can be written to /dev/random  and  /dev/urandom.  Data
     written  to  either special file is added to the generator's
     internal state. Data that is difficult to predict  by  other
     users  may  contribute randomness to the generator state and
     help improve the quality of future generated random numbers.

- Eric M Gearhart 15:32, 6 June 2008 (CDT)

Wikipedia's /dev/random article says: "Not all operating systems implement the same semantics for /dev/random." I wasn't trying to provoke an argument on the "nitty gritty" details of urandom, but at least something should be said about entropy and computer "random number generators," in order to err on the side of caution. Right? What you think? Eric M Gearhart 15:37, 6 June 2008 (CDT)

Sure :-), I agree completely. Your manpage was a bit more informative than mine. I will correct the mistake in the article soon and would be glad if you could look over it. Alexander Wiebel 05:12, 7 June 2008 (CDT)