I noticed that this parameter is reported on these systems as 4096, but the
man page (man 4 random) says it should normally be 512 (bytes). It also
goes on to say it can be changed to 32, 64, 128, 256, 512, 1024, 2048 which
I assume is bytes. 4096 bits = 512 byes, so it kinda makes sense. When I
The entropy pool size is configurable on some systems. For Linux see
/proc/sys/kernel/random/poolsize
Glenn
On Wed, Jun 11, 2008 at 7:52 AM, Bruce Keats <[EMAIL PROTECTED]> wrote:
> I forgot to mention that the systems in question are severs that do not
> have the keyboard or mouse as sources o
I forgot to mention that the systems in question are severs that do not have
the keyboard or mouse as sources of entropy. Yes indeed, the problem seems
a lack of entropy. What I find surprising is that on these systems, I seem
to be able to get approx 400 bytes from /dev/random and it doesn't mat
> What is the acceptable lower limit for the number of bytes for
RAND_load_file()?
Nobody can tell you what your requirements are. Some people will consider it
acceptable just to read 1KB from /dev/urandom. This is only a problem if the
entropy pool was never seeded, which is always at least poss
Glenn wrote:
Lack of entropy? Try using /dev/urandom
/dev/urandom supplies (statistically useful) random bits -- no
claims are made about entropy.
- M
__
OpenSSL Project http://www.openssl.org
On Tue, Jun 10, 2008 at 1:43 PM, Bruce Keats <[EMAIL PROTECTED]> wrote:
> I have noticed that some linux systems (CentOS 5.1, FC7 and FC8) that
> RAND_load_file("/dev/random", 1024) can take a long time (20 minutes).
>
>
Lack of entropy? Try using /dev/urandom
>From the man page: "/dev/random de
I have noticed that some linux systems (CentOS 5.1, FC7 and FC8) that
RAND_load_file("/dev/random", 1024) can take a long time (20 minutes). If I
do an strace on the process, I see that it is doing reads on /dev/random and
getting back 8 or 9 bytes. I assume that what is happening here is that
R
