[openssl-users] FIPS mode uses /dev/urandom ?

[John Foley]

You don't even need to modify e_os.h.  You can just pass in a new value
for DEVRANDOM using the gcc -D compiler option.  For instance, maybe you
have a hardware device mapped to a Linux device file called
/dev/entropy1.  You can override DEVRANDOM to use this device without
modifying any OpenSSL code.




On 03/12/2015 12:06 PM, Alberto Roman Linacero wrote:
> Well... I'm just trying, for the test, to do something like:
>
> debian:~/openssl# strace -xe trace=file,read,write,close
> /usr/local/ssl/bin/openssl rand 10
> [...]
> open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
> read(3, "\xa9\xea\xf3\x6e\x08\x14\xe7\xeb\x11\x9c\x72\x64\x69\x54\x0d\x96\x43\x34\x68\x25\xe3\x45\x8b\xe8\xe6\x36\xde\x9b\x33\x3a\x6a\xe2",
> 32) = 32
> close(3)                                = 0
>
> I know that it will have poor performance, and in fact I don't want to
> do this... but we're going to pass SP800 56b and they are asking us to
> use blocking to be sure that the entropy generated before the openssl
> seed is enough (256 entropy bits).
>
> My understanding of how OpenSSL seeds DRBGs is as follows:
>
> When initialization function is called, first the non-approved
> hash-based DRBG that is part of the baseline library is seeded. This
> DRBG is seeded according to library's settings (in e_os.h DEVRANDOM),
> and it defaults to /dev/urandom. After that approved FIPS-mode DRBG
> with 256-bit AES-CTR is seeded by calling the bytes() method. This
> way, output of the first non-approved DRBG is used to seed FIPS-mode
> DRBG. This is why module settings (e_os.h DEVRANDOM) are ignored.
>
> So, I'm not sure if I'm thinking it fine, or if I could change e_os.h
> to do that and still being FIPS certified, or...
>
> Alberto.
>
>
> 2015-03-11 21:10 GMT+01:00 Tom Francis <thomas.francis.jr at pobox.com>:
>>> On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero <aroman at alienvault.com> wrote:
>>>
>>> Dear all, I'm doing an strace to the FIPS validated version of
>>> openssl, and I'm seeing that is uses /dev/urandom. I thought that the
>>> FIPS validated module always use /dev/random, isn't this the case, or
>>> am I doing something wrong?.
>>>
>>> If it uses /dev/urandom, is it possible/advisable to change it to
>>> /dev/random (how?), and still the module being FIPS validated?
>> It would depend on what code is reading from /dev/urandom.  If it’s the FIPS Object Module that’s doing the reading, then no, absolutely not.  If it’s the FIPS-capable OpenSSL that reads from /dev/urandom, you can probably change it.  But I’m curious as to why you would want to do this.  Most systems with /dev/random and /dev/urandom are similar to Linux, in that /dev/urandom is the preferred source for “random data”, including when seeding a PRNG (which is how it’s used by OpenSSL).  And because /dev/random can block, you might have ridiculously poor performance (and worse, it’ll be unpredictably poor performance, i.e. sometimes it’ll work great, and other times it’ll be horrible, and you never which you’ll get).  This page, http://www.2uo.de/myths-about-urandom/ , is specific to Linux, but at a high-level, It’s also true for AIX, HP-UX, Solaris, FreeBSD, and NetBSD (OpenBSD is more complex).  I’m not about other UNIX-like systems, as I stopped using those before any of them ever provided such devices. :)
>>
>> TOM
>>
>>> Thanks for your help in advance and best regards,
>>> Alberto.
>>> _______________________________________________
>>> openssl-users mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>>
>> _______________________________________________
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>