This is RFC 4086, which was published in 2005. It's still listed as the current best practice, however much has happened since 2005, especially in the field of security.
So I wonder if there are some areas in which this document is lacking or which aren't holding up as well?
One thing I have picked up is randomness inside virtual machines, and issues surrounding that. Sure if you got hypervisor support you're golden, but what if you don't?
maqp · 2h ago
>So I wonder if there are some areas in which this document is lacking or which aren't holding up as well?
Ring oscillators have been embedded into Intel/AMD CPUs, and they're accessible via RDRAND/RDSEED. Blum-Blum-Shub has been phased out, these days you see AES-based CSRPNGs and Linux uses ChaCha20. The RNG in Linux has been overhauled at least once and so the /dev/random section is outdated.
Interestingly the key size recommendations were at around 90 bit range already 20 years ago, and they haven't changed that much. That's still quite close to the password minimum recommendation. Makes you wonder whether it should be closer to the 103 bits now.
Triple DES has been deprecated.
All in all, the guidance has changed. These days you should not be concerning yourself with any userland CSPRNG, just use the OS syscalls like GETRANDOM. Nothing you do above a kernel module RNG will make it more secure.
coderatlarge · 4h ago
from the intro:
“This Best Current Practice document describes techniques for
producing random quantities that will be resistant to attack. It
recommends that future systems include hardware random number
generation or provide access to existing hardware that can be used
for this purpose. It suggests methods for use if such hardware is
not available, and it gives some estimates of the number of random
bits required for sample applications.”
So I wonder if there are some areas in which this document is lacking or which aren't holding up as well?
One thing I have picked up is randomness inside virtual machines, and issues surrounding that. Sure if you got hypervisor support you're golden, but what if you don't?
Ring oscillators have been embedded into Intel/AMD CPUs, and they're accessible via RDRAND/RDSEED. Blum-Blum-Shub has been phased out, these days you see AES-based CSRPNGs and Linux uses ChaCha20. The RNG in Linux has been overhauled at least once and so the /dev/random section is outdated.
Interestingly the key size recommendations were at around 90 bit range already 20 years ago, and they haven't changed that much. That's still quite close to the password minimum recommendation. Makes you wonder whether it should be closer to the 103 bits now.
Triple DES has been deprecated.
All in all, the guidance has changed. These days you should not be concerning yourself with any userland CSPRNG, just use the OS syscalls like GETRANDOM. Nothing you do above a kernel module RNG will make it more secure.
“This Best Current Practice document describes techniques for producing random quantities that will be resistant to attack. It recommends that future systems include hardware random number generation or provide access to existing hardware that can be used for this purpose. It suggests methods for use if such hardware is not available, and it gives some estimates of the number of random bits required for sample applications.”