Am 23.09.2013 21:59, schrieb starlight.201...@binnacle.cx:
At 20:27 9/23/2013 +0200, Richard Könning wrote:
/dev/random is a PRNG which blocks when the (crude)
entropy estimation of the entropy pool falls below a
limit. Besides this there are afaik no big
differences between /dev/random and /dev/urandom.
In the sense that all TRNG outputs are run
through various algorithms that "mix" and
"whiten" the data to assure uniform statistical
distribution, all TRNGs could be called
PRNGs. However the crucial difference is
that TRNG post-filter output is irreproducible
where a "pseudo random number generator"
will predictably generate identical streams
of output given the same seed. So Intel's
RDRAND is a PRNG in the sense you seem
to be invoking.
[...]
/dev/urandom (in newer kernels) continually
re-seeds itself from the common entropy
pool but will apply TRNG when demand
exceeds supply. My desire is to experiment
According to my knowledge /dev/random and /dev/urandom work almost
identical between two consecutive reseeding operations, the only
difference being that /dev/random blocks when the entropy counter falls
below a limit thus limiting the delivery of random bytes between
reseeding operations (maybe in newer kernels there is some separation of
the entropy pool between the two devices, in older kernels they were
iirc using the same pool). That means, as long as /dev/random doesn't
block it operates in the same way as /dev/urandom and probably gives the
same random numbers with a given entropy pool content.
with having 'openssl' rely on the better
quality /dev/random source (enhanced by
a higher-volume input such as from a
TPM or RDRAND) at the cost of occasional
millisecond time-scale delays.
From random.c:
The two other interfaces are two character devices
/dev/random and /dev/urandom. /dev/random is
suitable for use when very high quality randomness
is desired (for example, for key generation or
one-time pads), as it will only return a maximum
of the number of bits of randomness (as estimated
by the random number generator) contained in the
entropy pool.
The /dev/urandom device does not have this limit,
and will return as many bytes as are requested.
As more and more random bytes are requested
without giving time for the entropy pool to
recharge, this will result in random numbers that
are merely cryptographically strong. For many
applications, however, this is acceptable.
If you can convince the kernel developers that
the above statement is incorrect and have a patch
accepted to modify the text, I'll abandon
my exploration of employing /dev/random. Until
then I find the random.c comments authoritative.
The random.c comments say the same as i wrote above: /dev/random blocks
when the (crude) entropy counter falls below a specific limit,
/dev/urandom not.
I certainly can an will dig into the code.
Merely posted here in the hope that someone
was familiar with the behavior of 'openssl'
in the face of blocked requests for random
bytes.
Well, when /dev/random is used and it blocks, then the initialization of
the OpenSSL PRNG will block too.
Ciao,
Richard
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
