Does it read entropy from /dev/urandom to protect hash table against "Algorithmic Complexity Attacks"? Is getrandom(2) the solution? Or init API that receives entropy from caller?
This Tweet was deleted by the Tweet author. Learn more
Conversation
On Linux, getrandom is always the right approach. The /dev/urandom and /dev/random APIs are obsolescent. They aren't always available since they require access to a populated /dev, there's the dynamic failure case from using dynamic allocation (of files) and the early init bug.
1
The maintainers should fix the early init security bug in /dev/urandom, but they aren't yet willing to do it based on the lackluster kernel entropy generation combined with broad deployment of broken environments not providing entropy such as poor virtual machine implementations.
Every system using the Linux kernel is vulnerable to potential issues comparable to the Debian OpenSSL CSPRNG breakage due to the /dev/urandom implementation. The /dev/urandom pool is the right one to use for nearly everything but the API is broken. It's crucial to use getrandom.
To save you some trouble: We're primarily talking about Linux systems where getrandom syscall returns ENOSYS or where there is no such syscall and there getentropy and friends all open /dev/urandom.
2
I believe we need to find solutions that don't require randomization & crypto at these layers (malloc and hashtables). I understand why people do it as defense-in-depth but I prefer approaches that solve these problems statically (e.g. avoiding memory-unsafe langs & hashtables).
1
1
Show replies