You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On OpenBSD, use getentropy(), which has a similar behavior and predates Linux' syscall.
getentropy(2) is meant to be used only to seed in-process RNGs. The man page for getentropy(2) says:
getentropy() fills a buffer with high-quality entropy, which can be used as input for process-context pseudorandom generators like arc4random(3).
[...]
getentropy() is not intended for regular code; please use the arc4random(3) family of functions instead.
Considering that, it may be more suitable advice to suggest arc4random(3) in the text for OpenBSD in particular. RAND_bytes in OpenBSD's LibreSSL just calls arc4random_buf(3) directly, which suggests that it is completely suitable for cryptographic usage.
Possibly you may want to have a distinct return code for /dev/urandom not existing in the example code: If it doesn't exist, there's absolutely nothing the program can do. (Furthermore, just reproducing substantial parts of the code from LibreSSL(-portable) without the copyright notice and license notice may be a violation of copyright/its license.)
The text was updated successfully, but these errors were encountered:
getentropy(2) on OpenBSD
Your text suggests using getentropy(2) on OpenBSD:
getentropy(2) is meant to be used only to seed in-process RNGs. The man page for getentropy(2) says:
Considering that, it may be more suitable advice to suggest arc4random(3) in the text for OpenBSD in particular.
RAND_bytes
in OpenBSD's LibreSSL just calls arc4random_buf(3) directly, which suggests that it is completely suitable for cryptographic usage.Incidentally, FreeBSD has finally changed their implementation away from RC4 to ChaCha20 as well, so it will be a safe bet even on there for versions >= 12.0 (but not the current 11.x series).
/dev/(u)random
The (u)random devices may be tampered with. I don't think there's a realistic threat model, but you may want to make people check the major and minor device numbers before opening /dev/(u)random just in case if they know the target platform.
Possibly you may want to have a distinct return code for /dev/urandom not existing in the example code: If it doesn't exist, there's absolutely nothing the program can do. (Furthermore, just reproducing substantial parts of the code from LibreSSL(-portable) without the copyright notice and license notice may be a violation of copyright/its license.)
The text was updated successfully, but these errors were encountered: