Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re^2: Your random numbers are not that random

by davies (Parson)
on Jul 22, 2012 at 15:43 UTC ( #983074=note: print w/replies, xml ) Need Help??

in reply to Re: Your random numbers are not that random
in thread Your random numbers are not that random

As you may see above in my reply to Cavac's post, there are random "devices" and I can get apparently random numbers. But I'm not actually trying to do anything with random numbers, which is why I find the response to perl -v idiosyncratic. The difference between the working card and the problem cards is that Perl was compiled on the working card and copied from there to the problem cards. Both cards had the same image copied to them using the same computer. Apart from Perl, everything works perfectly on both cards. I cannot see how the problem can be anything other than my failure to copy something from the working card to the problem cards, as the Perl creation process is the only difference. Sorry if my frustration is showing again.


John Davies

Replies are listed 'Best First'.
Re^3: Your random numbers are not that random
by cavac (Deacon) on Jul 22, 2012 at 19:27 UTC

    But on startup, perl is doing something with hashes i presume. Having no working random number generator is a big problem with hashes. Without it, there is a big problem with Denial of Service attacks. A simple use CGI; my $q = CGI->new; or using any other kind of hashes with user-supplied content can be a problem.

    So, if getting random numbers doesn't work, it is much better for perl to fail at startup than to fail silently and expose the system to all kinds of security problems.

    "I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"
Re^3: Your random numbers are not that random
by Anonymous Monk on Jul 23, 2012 at 01:04 UTC

    /dev/random and /dev/urandom are used to supply entropy (randomness) to the system. They both come from the same pool of randomness in the kernel. One blocks until enough randomness is obtained to provide a number. The other tries to make due with however much randomness the kernel has (and doesn't block).

    Haveged (and other programs) are means to supply the kernel with randomness. By default, haveged manages a 1M buffer of randomness. Haveged does not appear to keep open a file for this buffer of randomness, so perhaps it doesn't write the buffer to disk on shutdown.

    But in any event, it seems to build the pool of randomness in the kernel faster than most other things I've tried.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://983074]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (2)
As of 2018-05-28 02:10 GMT
Find Nodes?
    Voting Booth?