Hacker News Reader

Comment by charcircuit | Hacker News Reader

>The /dev/random is the “very foundation” of cryptography on Linux, developer Stephan Müller told The Daily Swig. “If /dev/random breaks, the entire cryptography on Linux is broken,” Müller said.

I thought using /dev/random was depricated and that you should instead use a getrandom syscall that blocks if you don't have enough entropy.

View on HN

Since Linux 5.6, /dev/random only blocks during initialization until it gets the initial entropy, and behaves like /dev/urandom afterwards.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

/dev/random does block "if you don't have enough entropy" (in contrast to /dev/urandom, which doesn't). The only difference is that getrandom() doesn't require a file descriptor to use.

Note that "if you don't have enough entropy" is not based on any rigorous formal analysis, which is why /dev/urandom has been recommended for a long time, and why the entire concept of blocking randomness syscalls is controversial in kernel-land:

https://lwn.net/Articles/800509/

You're right, but when kernel developers talk about /dev/random they generally mean the underlying RNG, not the interface by which you access it. To a userland developer the phrase "read from /dev/random via the getrandom system call" is nonsense but to a kernel developer it sounds reasonable.

in the the man page they say only legacy

> The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted. It will return random bytes only within the estimated number of bits of fresh noise in the entropy pool, blocking if necessary. /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays.

and recommend:

> Linux 3.17 and later provides the simpler and safer getrandom(2) interface which requires no special files; see the getrandom(2) manual page for details.

> blocks if you don't have enough entropy

Which, in most cases I can think of is a rather undesirable behavior.

I would really be interested to understand which use cases justify using an actual blocking call to retrieve random bits.

I've always been under the impression that the only valid use case for raw entropy bits is regularly seeding crypto-hard RNGs that can generate an endless stream of random bits (à la /dev/urandom).

Looking forward to being educated on the topic.

Correct behavior: Block (or don’t be available) until you can securely generate an effectively endless stream of random bits, then never.

Correct API: https://fuchsia.dev/fuchsia-src/reference/syscalls/cprng_dra...

I decided to have a quick look, and this caught my eye: —- zx_cprng_draw() terminates the calling process if buffer is not a valid userspace pointer. ——

”Terminates the calling process”? That sounds different and interesting, do you know more about this aspect of Fuchsia?

I'm not too familiar with Fuchsia, but other syscalls return ZX_ERR_INVALID_ARGS so I suspect the idea was to keep this particular, security-critical call as simple as possible. This behavior shouldn't break any code that wasn't already broken.

> I would really be interested to understand which use cases justify using an actual blocking call to retrieve random bits.

The only case I can think of is when you've mass produced a million devices that each need unique certificates that are generated on first boot. If no good source of randomness is available, there's a decent risk you'll have duplicates.

https://crypto.stackexchange.com/questions/9694/technical-de...

Reply on news.ycombinator.com