Talk:Unix directory structure: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Alexander Wiebel
(→‎urandom and random: new section)
imported>Eric M Gearhart
Line 18: Line 18:
   your application, use /dev/random instead.
   your application, use /dev/random instead.
--[[User:Alexander Wiebel|Alexander Wiebel]] 10:30, 7 February 2008 (CST)
--[[User:Alexander Wiebel|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'):
<pre>
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.
</pre> [[User:Eric M Gearhart|Eric M Gearhart]] 15:32, 6 June 2008 (CDT)

Revision as of 14:32, 6 June 2008

This article is a stub and thus not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition A convention of the organization of the directory structure in Unix-like operating systems. [d] [e]
Checklist and Archives
 Workgroup category Computers [Categories OK]
 Talk Archive none  English language variant British English

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)