Re: [openssl-users] FIPS mode uses /dev/urandom ?
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 -- Alberto Román Engineering team http://www.alienvault.com Mobile: +34 605804179 Phone: + 91 5151344 Email: aro...@alienvault.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode uses /dev/urandom ?
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
[openssl-users] FIPS mode uses /dev/urandom ?
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? Thanks for your help in advance and best regards, Alberto. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode uses /dev/urandom ?
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
