,
8 tweets,
2 min read
Read on Twitter
1/ So people, I struggle with this problem and I'd like your help on solving it. As far as I can tell, there is no "just use...." answer to this problem, and I've spent a long time looking for one.
2/ 'getrandom()' is based on a system call that didn't appear until Linux/3.17. However, Linux/3.16 kernels are still common. For example, one of my test systems is an Odroid-C2 which has Ubuntu 18 on a Linux kernel 3.16. Yes, userland and kernel are widely different.
3/ This is a 'new' Odroid-C2, mind you. In the ARM world, hardware supports whichever kernel is newest when they ship and almost never change the kernel version, even as userland is updated.
4/ getrandom() uses /dev/urandom, which uses a CSPRNG based on an entropy seed, rather than based purely on entropy. This is proper, but some idiots think that /dev/random is better because it's got more entropy. However...
5/ However, at startup, there isn't yet enough entropy to seed /dev/urandom or getrandom(), so it they can block. You sometimes want your program to startup fast and not block, so you may grab RDRAND yourself to get entropy.
6/ Portable code doesn't have getrandom() (that's a Linux thing), and as mentioned above, older kernels don't have it either. /dev/urandom is portable though, but unfortunately, often isn't available inside containers. So you end up having to solve this problem yourself.
7/ If you look across the world of open-source projects, you find a lot of fixes for this. They generally grab arc4random from OpenBSD as the CSPRNG and scavaning entropy themselves to seed it with.
8/ There are lots of places to grab entropy. One sneaky way is to grab the ASLR locations of code/data. While time() gives very few bits of entropy, clock_gettime() with microsecond precision gets a lot more. Walking parts of the filesystem getting file names/timestamps gets more
