random: Do not trust arc4random_buf() on glibc #10390
Conversation
This effectively reverts php#8984. As discussed in php#10327 which will enable the use of the getrandom(2) syscall on NetBSD instead of relying on the userland arc4random_buf(), the CSPRNG should prioritize security over speed [1] and history has shown that userland implementations unavoidably fall short on the security side. In fact the glibc implementation is a thin wrapper around the syscall due to security concerns and thus does not provide any benefit over just calling getrandom(2) ourselves. Even without any performance optimizations the CSPRNG should be plenty fast for the vast majority of applications, because they often only need a few bytes of randomness to generate a session ID. If speed is desired, the OO API offers faster, but non-cryptographically secure engines.
There was a problem hiding this comment.
Hmm, unsure about this. @crrodriguez commented:
You do not need to revert it. it is safe.. and will later be improved as kernel/libc versions advance.
I think both of you have a point. But regardless which solution we prefer, we should probably add a brief comment in the source code, so we won't switch back and forth over time.
That comment will be added by @devnexen's #10327 and is already part of that PR. The revert for glibc is also consistent with NetBSD's migration to the syscall. I wanted to get this PR out first, such that devnexen's comment is actually factually accurate. I also hope to clean up the whole CSPRNG implementation a little further, the removal of the
I believe that any kind of userland solution is unsafe. If glibc is just a thin wrapper around getrandom(2) (as it is now) then it does not bring us any benefit, we need to maintain the getrandom(2) logic anyway. If glibc does more than wrapping getrandom(2), then it is likely unsafe. |
* PHP-8.2: random: Do not trust arc4random_buf() on glibc (#10390)
Targeting PHP-8.2, because the the original PR was landed in PHP-8.2 and it does not appear to be useful to allow this for the entirety of 8.2 only, but no other branch.
/cc @crrodriguez
This effectively reverts #8984.
As discussed in #10327 which will enable the use of the getrandom(2) syscall on NetBSD instead of relying on the userland arc4random_buf(), the CSPRNG should prioritize security over speed [1] and history has shown that userland implementations unavoidably fall short on the security side. In fact the glibc implementation is a thin wrapper around the syscall due to security concerns and thus does not provide any benefit over just calling getrandom(2) ourselves.
Even without any performance optimizations the CSPRNG should be plenty fast for the vast majority of applications, because they often only need a few bytes of randomness to generate a session ID. If speed is desired, the OO API offers faster, but non-cryptographically secure engines.