On Fri, Oct 23, 2015 at 03:22:39PM +0200, Alessandro Ghedini wrote: > Hello everyone, > > (sorry for the wall of text...) > > one of the things that both BoringSSL and LibreSSL have in common is the > replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner > alternative. Given RAND_SSLeay() complexity I think it'd be worth to at least > consider possible alternatives for OpenSSL.
I think at least a few of us want to see something changed, but I'm not sure what direction it's going to go. > BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to > RAND_bytes(). Additionally, if the RDRAND instruction is available, the output > of RDRAND is mixed with the output of the system RNG using ChaCha20. This uses > thread-local storage to keep the global RNG state. The problem with only relying on /dev/urandom on Linux is that it can give you data without having had enough entropy feed in it first. At least getrandom() will fix that, but that's only in the kernel since 3.17 and a lot of people still don't have that. But maybe most people will actually have it on systems that are going to run 1.1. This is of course not a new problem, we also already have that now. I think some people have concerns about only relying on the OSs RNG and instead want to get a high entropy seed from it and use that to feed our own RNG. We might use a better (by whatever definition) algorithm than the kernel is using. Only using /dev/urandom might result in people complaining that we start to drain their available entropy. I don't know enough about the Linux kernel's implementation of the RNG, but their calculation just seems wrong to me. > Incidentally, BoringSSL added a whole new API for thread-local storage which > OpenSSL could adopt given that e.g. the ASYNC support could benefit from it > (there are other interesting bits in BoringSSL, like the new threading API > that > could also be adopted by OpenSSL). Threads, and so thread-local storage, is all very OS specific. And I'm afraid we don't have that on all platforms we still want to support. But I think that belongs in a different discussion. > The BoringSSL method is very simple but it needs a read from /dev/urandom for > every call to RAND_bytes() which can be slow (though, BoringSSL's RAND_bytes() > seems to implement some sort of buffering for /dev/urandom so the cost may be > lower). An other issue is that /dev/urandom might not be available in a chroot or when you run out of file descriptor. The chroot is at least something the LibreSSL seems to be running in to, but is nothing we can really do about on all OSs. > On the other hand, LibreSSL replaced the whole RAND_* API with calls to > OpenBSD's arc4random(). This is a nice and simple scheme that uses ChaCha20 to > mix the internal RNG state, which is regularly reseeded from the system RNG. I think the arc4random() thing is such a misleading name since it doesn't have anything to do with (A)RC4 anymore. I'm also not sure that the implementation with ChaCha20 is the best way to go, you could also go for something like Fortuna, or stay with whatever we use now. We currently don't reseed, and I have no idea what amount of data we should be able to safely extract from it now, I think it's rather large, but reseeding should never hurt. Kurt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
