Entropy for TLS 1.2: how much is needed for linux servers?

I am trying to fix issues with a server where the server keeps freezing up and needs to be restarted. I recently started hearing about entropy and it importance to secure tls keys in linux. The one thing I haven't found in my research is, how much is needed/how to increase entropy on a linux server for TLS 1.2.

I believe this is where the issue is coming from. It started to appear when we were implementing TLS 1.2 and the randomness might not be high enough.

Have done some research on the topic, talked to a few other higher level developers but no one seems to be ale to point me in the write direction.

While it's quite possible that any daemon (I mean MySQL in particular since my employer had trouble with it before we increased our RAM capacity) can cause a freeze, let's focus on entropy source for PRNGs since the topic of our site is cryptography.

The common practice is to use the /dev/urandom device for practically all of the randomness source.

• On Linux, this special device does not block at all - not even when the "estimated" entropy of its seed material is low.

• On BSDs, /dev/random and /dev/urandom behaves identically, as their developers believe that any properly designed PRNG algorithm can meet the demand even when just bare-minimum entropy is fed.

So the cryptographic advice to your problem, is to switch to /dev/urandom in your configuration.

References:

• FreeBSD man page

• Linux man page

Also, keep updating software regularly (I convinced my employer to do so once a month), because if this is indeed a bug, it may get fixed in some version.

The proper interface to use on Linux is getrandom, which is available in most Linux distros these days. The interface will block until the CSPRNG is initialized on startup (unless GRND_NONBLOCK is specified) and never again.

That ensures that you have at least 256 bits of entropy on the system, which is enough to generate all the keys you could possibly need. The system will continually reseed the CSPRNG with new entropy as it goes along as well. Note that making sure the CSPRNG is seeded on Linux is very easy if you have a hardware RNG like RDRAND or RDSEED and you've configured CONFIG_RANDOM_TRUST_CPU in your kernel (most distros do).

On FreeBSD, getrandom is also available, and you can use getentropy or arc4random on any of the BSDs. (Technically, those are also available on Linux, but only in more recent versions of glibc.) To my knowledge, the BSDs by default ensure the OS CSPRNG is seeded appropriately on startup, provided writable media exist. See the random(4) page for your BSD for details.

On most varieties of Unix, /dev/urandom can be used as well, but on Linux it doesn't guarantee that the CSPRNG has been appropriately seeded. That's why using getrandom or getentropy is preferred.

On Windows, RtlGenRandom is the right interface.

Note that if your system is hanging after the machine has been up and serving TLS requests for a while, then it isn't a lack of entropy, because all major operating systems continue to serve data from the system CSPRNG after it's initially seeded. As mentioned, 256 bits of entropy is sufficient to generate a virtually unlimited amount of random data on the system (especially considering the fact that you'll reboot now and again for kernel security updates), so there's no need to block once correctly seeded.