Re: RAND_load_file takes a long time to load 1K bytes from /dev/random
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 matter how long the system has been running for (hours, days, weeks or months). This seems a little odd to me. Bruce On Tue, Jun 10, 2008 at 11:25 PM, David Schwartz [EMAIL PROTECTED] wrote: 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 possible. If you aren't comfortable reading from /dev/urandom, an acceptable compromise might be to read a small number of bytes from /dev/random (accepting that this might take a while in exchange for a stronger guarantee of security) and a larger number of bytes from /dev/urandom (in the hopes that this will increase security because it is quite likely to do so). IMO, 16 or 32 bytes from /dev/random and 256 bytes from /dev/urandom is sufficient for almost all imaginable applications. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RAND_load_file takes a long time to load 1K bytes from /dev/random
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 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 matter how long the system has been running for (hours, days, weeks or months). This seems a little odd to me. Bruce On Tue, Jun 10, 2008 at 11:25 PM, David Schwartz [EMAIL PROTECTED] wrote: 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 possible. If you aren't comfortable reading from /dev/urandom, an acceptable compromise might be to read a small number of bytes from /dev/random (accepting that this might take a while in exchange for a stronger guarantee of security) and a larger number of bytes from /dev/urandom (in the hopes that this will increase security because it is quite likely to do so). IMO, 16 or 32 bytes from /dev/random and 256 bytes from /dev/urandom is sufficient for almost all imaginable applications. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RAND_load_file takes a long time to load 1K bytes from /dev/random
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 try and change the value with sysctl -w kernel.random.poolsize=2048 as root I get error: permission denied on key 'kernel.random.poolsize' Bruce On Wed, Jun 11, 2008 at 2:18 PM, Glenn [EMAIL PROTECTED] wrote: 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 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 matter how long the system has been running for (hours, days, weeks or months). This seems a little odd to me. Bruce On Tue, Jun 10, 2008 at 11:25 PM, David Schwartz [EMAIL PROTECTED] wrote: 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 possible. If you aren't comfortable reading from /dev/urandom, an acceptable compromise might be to read a small number of bytes from /dev/random (accepting that this might take a while in exchange for a stronger guarantee of security) and a larger number of bytes from /dev/urandom (in the hopes that this will increase security because it is quite likely to do so). IMO, 16 or 32 bytes from /dev/random and 256 bytes from /dev/urandom is sufficient for almost all imaginable applications. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RAND_load_file takes a long time to load 1K bytes from /dev/random
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 RAND_load_file() is reading the available pool of entrogy, finds it is not 1K then RAND_load_file() blocks on subsequent reads from /dev/random returning 8 bytes (/proc/sys/kernel/random/read_wakeup_threadhold is 64 or 8 bytes) of entropy as it becomes available. When I look at /proc/sys/kernel/random/entropy_avail, the number is typically 3590 or so even on systems that have been running for awhile. The poolsize as reported by /proc/sys/kernel/random/poolsize is reported as 4096. Is this what I should expect from RAND_load_file() and /dev/random? What is the acceptable lower limit for the number of bytes for RAND_load_file()? Bruce
Re: RAND_load_file takes a long time to load 1K bytes from /dev/random
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 device will only return random bytes within the estimated number of bits of noise in the entropy pool... When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered Glenn
Re: RAND_load_file takes a long time to load 1K bytes from /dev/random
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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: RAND_load_file takes a long time to load 1K bytes from /dev/random
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 possible. If you aren't comfortable reading from /dev/urandom, an acceptable compromise might be to read a small number of bytes from /dev/random (accepting that this might take a while in exchange for a stronger guarantee of security) and a larger number of bytes from /dev/urandom (in the hopes that this will increase security because it is quite likely to do so). IMO, 16 or 32 bytes from /dev/random and 256 bytes from /dev/urandom is sufficient for almost all imaginable applications. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
