<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"> <span>If you are going to make all that effort you may as well go for FIPS compliance as the default.<br><br>SP800-90 A/B/C do cover the areas of concern, the algorithms are simple and clear as is the overall flow of processing to start from 'noise' to produce safe and reliable TRNG/PRNG's.<br></span><span><span> More importantly, you already have most of the necessary code in OpenSSL-FIPS.<br></span></span><br><span><span>And you can always swap out AES/SHA in the core for other 
algorithms to cater for the very paranoid and those who don't trust US algorithms, or just leave the RNG code 'pluggable' as it is now.
<br><br></span>Peter<br><br><br></span><br><font color="#990099">-----"openssl-dev" <<a target="_blank" href="mailto:openssl-dev-bounces@openssl.org">openssl-dev-bounces@openssl.org</a>> wrote: -----</font><div class="iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">To: <a target="_blank" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a><br>From: Benjamin Kaduk <bkaduk@akamai.com><br>Sent by: "openssl-dev" <openssl-dev-bounces@openssl.org><br>Date: 10/24/2015 08:46AM<br>Subject: Re: [openssl-dev] Improving OpenSSL default RNG<br><br><div><font face="Courier New,Courier,monospace" size="2">On 10/23/2015 08:22 AM, Alessandro Ghedini wrote:<br>> Hello everyone,<br>><br>> (sorry for the wall of text...)<br>><br>> one of the things that both BoringSSL and LibreSSL have in common is the<br>> replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner<br>> alternative. Given RAND_SSLeay() complexity I think it'd be worth to at least<br>> consider possible alternatives for OpenSSL.<br><br>I heartily support this; the existing RAND_SSLeay() is a bit frightening<br>(though I take some solace in the existence of ENGINE_rdrand()).<br><br>> BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to<br>> RAND_bytes(). Additionally, if the RDRAND instruction is available, the output<br>> of RDRAND is mixed with the output of the system RNG using ChaCha20. This uses<br>> thread-local storage to keep the global RNG state.<br><br>/dev/urandom is simple and safe absent the chroot case.  (Note that<br>capsicum-using applications will frequently open a fd for /dev/urandom<br>before entering capability mode and leave it open; the same might be<br>worth considering.)  Concerns about "running out of entropy" are<br>unfounded; the kernel uses a CS-PRNG and if we trust its output to seed<br>our own scheme, we can trust its output indefinitely.<br><br>Intel recommends calling RDRAND in a loop since it does not always<br>return successfully, and IIRC best practice is to mix it in with other<br>inputs (i.e., not use it directly).<br><br>> Incidentally, BoringSSL added a whole new API for thread-local storage which<br>> OpenSSL could adopt given that e.g. the ASYNC support could benefit from it<br>> (there are other interesting bits in BoringSSL, like the new threading API that<br>> could also be adopted by OpenSSL).<br>><br>> The BoringSSL method is very simple but it needs a read from /dev/urandom for<br>> every call to RAND_bytes() which can be slow (though, BoringSSL's RAND_bytes()<br>> seems to implement some sort of buffering for /dev/urandom so the cost may be<br>> lower).<br><br>Keeping the default method simple, slow, and reliable could be a<br>reasonable approach, given that there is always the option of inserting<br>an alternate implementation if performance is a concern.  ("Simple"<br>probably means "rely on the kernel for everything, do not use<br>thread-local storage, etc.")<br><br>It might also be worth having a more complicated scheme that does use<br>thread-local storage (on systems where we know how to implement it) and<br>runs fortuna or something similar, but that does not necessarily need to<br>be the default implementation, in my opinion.<br><br>><br>> On the other hand, LibreSSL replaced the whole RAND_* API with calls to<br>> OpenBSD's arc4random(). This is a nice and simple scheme that uses ChaCha20 to<br>> mix the internal RNG state, which is regularly reseeded from the system RNG.<br>> The core logic of this (excluding ChaCha20 and platform-specific bits) is<br>> implemented in less than 200 lines of code and, at least in theory, it's the<br>> one that provides the best performance/simplicity trade-off (ChaCha20 can be<br>> pretty fast even for non-asm platform-generic implementations).<br><br>A single syscall to get entropy is nice, whether it's a sysctl node,<br>getentropy(), getrandom(), or some other spelling; a library call like<br>arc4random() is almost as good.  But I don't think we're in a position<br>to rip out the RAND_* API layer as LibreSSL did.<br><br>> Both of these methods are robust and mostly platform-indipendent (e.g. none of<br>> them uses the system time, PID or uninitilized buffers to seed the RNG state)<br>> and have simple implementations, so I think OpenSSL can benefit a lot from<br>> adopting one of them. The astute readers may point out that OpenSSL doesn't<br>> support ChaCha20 yet, but that's hopefully coming soon.<br>><br>> I think there's also room for improvement in the platform-specific RAND_poll()<br>> implementations, e.g.:<br>><br>> - on Linux getrandom() should be used if available<br>> - on OpenBSD getentropy() should be used instead of arc4random()<br>> - the /dev/urandom code IMO can be simplified<br>> - the non-CryptGenRandom() code on Windows is just crazy. Do we even support<br>>   Windows versions before XP?<br>> - is EGD actually used anywhere today?<br><br>"I really hope not."<br><br>> - what about Netware, OS/2 and VMS, do we have any users on them? IIRC support<br>>   for other platforms has already been removed, what are the criteria for<br>>   keeping support for one?<br>> - etc...<br>><br>> For comparison, OpenBSD's getentropy() implementation [0] is much cleaner and<br>> supports many of the platforms supported by OpenSSL.<br>><br>> So, any thought? If there's interest in this, I can look into investigating<br>> these things more in detail and propose possible patches.<br>><br><br>I'll just note in closing that there are a number of "fortuna-like"<br>implementations out there that are not actually fortuna, for example,<br>were implemented based off of the wikipedia article and not the actual<br>textbook. <br><a href="https://github.com/krb5/krb5/blob/master/src/lib/crypto/krb/prng_fortuna.c">https://github.com/krb5/krb5/blob/master/src/lib/crypto/krb/prng_fortuna.c</a><br>was implemented from _Cryptography Engineering_, and I think<br><a href="https://github.com/freebsd/freebsd/blob/master/sys/dev/random/fortuna.c">https://github.com/freebsd/freebsd/blob/master/sys/dev/random/fortuna.c</a><br>is another.<br><br>-Ben<br>_______________________________________________<br>openssl-dev mailing list<br>To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br><br></font></div></openssl-dev-bounces@openssl.org></bkaduk@akamai.com></div></div></font><BR>