News for hackers. Stuff that matters.

A comment on On Linux's Random Number Generation.

Re:On Linux's Random Number Generation by xmmrm on Friday December 20, 2019 @06:37PM (#21848354)
For comparison, here‘s a sane interface: https://fuchsia.dev/fuchsia-src/reference/syscalls/cprng_dra...
[ Parent | on HN ]
Re:On Linux's Random Number Generation by saagarjha on Friday December 20, 2019 @08:51PM (#21849038)
How is this different from read(open("/dev/random", O_RDONLY), buffer, sizeof(buffer))?
[ Parent | on HN ]
Re:On Linux's Random Number Generation by dchest on Saturday December 21, 2019 @04:15AM (#21850470)
- It won't fail if there's no /dev/random device mounted (e.g. in chroot)

- It won't fail if there are no file descriptors available

- No error handling needed: the call always succeeds and random bytes are always returned

[ Parent | on HN ]
Re:On Linux's Random Number Generation by ben_bai on Saturday December 21, 2019 @05:00AM (#21850587)
So like the standard arc4random_buf(3) which everybody has except for Linux.

Don't worry the name is historic it does not us the arc4 cipher any longer, at least on OpenBSD. They switched to chacha20 as stream cipher.

[ Parent | on HN ]
Re:On Linux's Random Number Generation by dchest on Saturday December 21, 2019 @05:41AM (#21850683)
The interface is the same, but arc4random_buf is a user-space CSPRNG.

The analog of zx_cprng_draw is getentropy(2): http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/... except zx_cprng_draw kills the process, while getentropy returns an error.

[ Parent | on HN ]
Re:On Linux's Random Number Generation by cyphar on Saturday December 21, 2019 @05:55AM (#21850723)
Linux has had getrandom(2) for quite a few years, and there are glibc wrappers which use it.
[ Parent | on HN ]