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...@pobox.com>:
>>> On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero
>>> <aro...@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
>
>
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
