Going through these it seems they've gone to a whole lot of trouble to implement something no one really needs (an extra layer for entropy management). Their re

Going through these it seems they've gone to a whole lot of trouble to implement something no one really needs (an extra layer for entropy management). Their reasoning seems to be: 1) OpenSSL seeds its CSPRNG once on startup from /dev/urandom 2) A Linux server will often have low entropy when responding to that call 3) The OpenSSL CSPRNG is thus compromised and some extra logic is needed to only take the value once there's enough entropy The thing is 2) is not really a problem. As long as the pool had enough entropy at the beginning to seed the /dev/urandom CSPRNG the output is good forever even if the pool is now empty. I think most distros already make sure /dev/urandom is properly seeded on startup so there should be no real attack here. On 3) we should probably be going the other way (less code). Apparently OpenSSL actually has its own CSPRNG instead of just reading from /dev/urandom when it needs random numbers. Maybe there's a valid performance reason to do that (less context switches) but I doubt it.