Entropy isn't depleted by having a CSPRNG generate random data. Using the nonsensical Linux /dev/random API instead of getrandom() is a bug. Other operating systems like OpenBSD don't provide a faulty /dev/random implementation at all. It really shouldn't be used on Linux at all.
Conversation
Linux /dev/urandom is faulty and returns data before being initialized. Linux /dev/random API is faulty and uses a nonsensical cargo cult design blocking after initialization without providing meaningful security properties from it. Software not using getrandom() is just broken.
1
I am sorry, but what you've just said is utterly false. getrandom just proxy for urandom/random.
Additionally the only worry with URANDOM if you have never started the machine. OSs are saving the seed between the cycles, so that there is always propagation of entropy.
1
It's completely accurate and you're just misinterpreting what I said and making a strawman argument. I never said it used a different pool than urandom but rather than the API is sane since it won't ever return data when uninitialized. I clearly explained it in the other thread.
1
The /dev/random API is a nonsense concept not based on any real threat model, security rationale or cryptographic basis. It doesn't actually provide a property like better backwards secrecy. It doesn't make sense to use it either via the legacy file API or the getrandom flag.
1
1
The rationale for programs using /dev/random has always been that /dev/urandom could be uninitialized, and the getrandom API eliminates that rationale by fixing the problem. Saving / restoring entropy between boot is useful and is done by Android and systemd but that isn't a fix.
1
The first boot matters, and there isn't necessarily enough entropy generated even for use during the subsequent boots. Many of the real world issues caused by low entropy keys occurred on embedded devices during the initial boot. They generate keys on first boot to start working.
1
It's also important to note that the Linux man pages are not an authoritative source and have often been inaccurate. Look at `man 4 random` on an up-to-date distribution (which says what I did) and compare it to the totally inaccurate cargo cult advice it gave in the recent past.
1
1
It now says "The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted." which is decent advice but misleading since the pools used to use the same implementation.
1
1
That statement is also implying that the getrandom flag for using the /dev/random pool is a legacy interface too, since the same reasoning applies. Their wording is too kind since it doesn't mention that approach was total nonsense, and that their old advice was completely wrong.
1
The man pages are not provided by the kernel. It's a separate project, not maintained by the kernel developers. The people who write them are often not experts or even very familiar with the topics they're covering. That's how `man 4 random` was so terrible until very recently.