[Olsr-dev] /dev/random can block forever - Re: [PATCH v1 1/1] main: improve random number generator seed

Björn Lichtblau (spam-protected)
Sat Mar 23 00:19:21 CET 2013


Hi,

/dev/random can block forever if not enough entropy is available. It 
does on my systems, the problem is described here in detail:
http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty/

Works fine for me when using /dev/urandom, what should be the default 
imho, it never blocks and pseudo random numbers should be enough if it 
is just used for the jitter.

 From "man 4 random":

        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 environ-
        mental 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 unclassified lit-
        erature, but it is theoretically possible that such an attack 
may exist.  If this is  a
        concern in your application, use /dev/random instead.

    Usage
        If you are unsure about whether you should use /dev/random or 
/dev/urandom, then proba-
        bly you want to use the latter.  As a general rule, 
/dev/urandom  should  be  used  for
        everything except long-lived GPG/SSL/SSH keys.


bye, Björn




On 10.11.2012 11:50, Ferry Huberts wrote:
> From: Ferry Huberts <(spam-protected)>
>
> Make it much more random when /dev/random or /dev/urandom is
> available.
>
> Signed-off-by: Ferry Huberts <(spam-protected)>
> ---
>   src/main.c | 24 +++++++++++++++++++++++-
>   1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/src/main.c b/src/main.c
> index ae38439..382c5dc 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -230,6 +230,28 @@ olsrmain_load_config(char *file) {
>     return 0;
>   }
>   
> +static void initRandom(void) {
> +  unsigned int seed = (unsigned int)time(NULL);
> +
> +#ifndef _WIN32
> +  int randomFile;
> +
> +  randomFile = open("/dev/random", O_RDONLY);
> +  if (randomFile == -1) {
> +    randomFile = open("/dev/urandom", O_RDONLY);
> +  }
> +
> +  if (randomFile != -1) {
> +    if (read(randomFile, &seed, sizeof(seed)) != sizeof(seed)) {
> +      ; /* to fix an 'unused result' compiler warning */
> +    }
> +    close(randomFile);
> +  }
> +#endif /* _WIN32 */
> +
> +  srandom(seed);
> +}
> +
>   /**
>    * Main entrypoint
>    */
> @@ -297,7 +319,7 @@ int main(int argc, char *argv[]) {
>     olsr_openlog("olsrd");
>   
>     /* setup random seed */
> -  srandom(time(NULL));
> +  initRandom();
>   
>     /* Init widely used statics */
>     memset(&all_zero, 0, sizeof(union olsr_ip_addr));

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20130323/39761989/attachment.html>


More information about the Olsr-dev mailing list