On Thu, Apr 19, 2012 at 8:52 AM, Kevin Fowler <[email protected]> wrote:
2. I am using OpenSSL/FIPS on a system with /dev/urandom. Although the rand_unix.c RAND_poll() function is called only once with the released code, after the system has been up for a bit after reboot, I have assumed that the read from /dev/urandom obtained sufficient entropy. That is, the "ok" test in ssleay_rand_bytes() will always be true. Am I being naive? I do not get any errors ever, but I have been using RAND_bytes without checking the return code, since from what I can tell if the ok is true once, it will always be true unless my application makes another call to RAND_poll() if RAND_bytes returns 0. With Thor's patch however, the RAND_bytes call would itself boost the entropy with calls to RAND_poll if the initial call was not enough. Maybe it is not an issue with /dev/urandom?
/dev/urandom will never block when there is insufficient entropy to meet the demand, and has no means to inform the reader if there is insufficient entropy. Thus, using it is generally considered "bad". The flip side is that you have /dev/random, which probably means you have a persistent entropy pool across reboots. This is something you should look into, as /dev/random and /dev/urandom use the same pool. If you have enough entropy from prior boots, there's less to worry about. Note: There are no absolutes in cryptography. Just because something is generally considered 'bad' does not mean that it's always bad, and just because something is generally considered 'good' does not mean that it's always useful or desirable. If something is considered 'bad', it means only that the problem that the badness can lead to must be addressed in another part of the system. The final analysis matters. "Does it help me do my job/live my life more easily? No? Then what did I give you money for?" I do not comment on the patch because I feel unqualified to do so at this time. -Kyle H
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature
