Hacker News Reader

Comment by tedunangst | Hacker News Reader

so if the libressl developers rip out all their dubious entropy generation methods in favor of /dev/urandom on linux it might be well worth switching to it.

/dev/urandom is the favored entropy gathering method. But if you can't open it (not there, rlimit restriction, etc.) it falls back to the bobo code. If the linux kernel provided a random number source that was reliable and could not fail, this wouldn't be an issue.

View on HN

How is it a good thing to fall back to non sufficient security? The only good fallback is falling back to crash and clean up. If libressl can't find enough entropy then it should give up on it.

It does seem kind of odd to criticize the release for having -Werror on by default and also for having a fallback if /dev/urandom is unavailable.

In the former case they are sacrificing portability for increased confidence of correctness, and in the latter they are sacrificing confidence or correctness for increased portability.

I won't argue that point since I generally agree, but ask yourself this:

0. sshd will fork() and chroot() into /var/empty. After the fork(), you can't use the entropy you have because it's shared with the parent (i.e., it's not "entropic").

1. Where should it get entropy from?

2. Where does OpenSSL get entropy from in this case?

Anyway, I don't even work on portable libressl because I don't want to deal with shit like this, but I think the quoted text erroneously gives the impression that /dev/urandom isn't used. I wanted to correct that impression.

With OpenSSL, if you know you're going be chrooting, you can explicitly seed the internal PRNG with a call to RAND_poll() before you chroot, avoiding the need to open /dev/urandom once you've chrooted. (Similarly, you're supposed to call RAND_poll() to re-seed after forking because there's no safe way to detect that you've forked. Of course, if you fork while in a chroot you're screwed.)

I really think that LibreSSL's RAND_poll() should have similar behavior to ensure maximum compatibility with OpenSSL and to provide a means to use chroot() safely without the risk of falling back to the "bobo" code. (Also, a means of safely reseeding after a fork on systems without minherit(MAP_INHERIT_ZERO)).

(Incidentally, libsodium has a similar API: you can explicitly call randombytes_stir() to cause the library to open (and keep open) a file descriptor to /dev/urandom, so subsequent calls to the PRNG work in a chroot.)

Yes, that's what you're supposed to do, and it sucks. A good library should provide you with more than a box full of hammers and thumbs; it should actually help you and not just punt whenever a hard decision shows up. The RAND interface was one of the first things gutted.

The presence or need for a stir() function should be considered a serious design flaw.

(forks are detected by calling getpid() if you don't have inheritzero.)

Agreed, but the lack of a random syscall on Linux makes an API like stir necessary.

Also, getpid() isn't airtight - if you fork and fork again there's a risk of PID wraparound.

> sshd will fork() and chroot() into /var/empty. After the fork(), you can't use the entropy you have because it's shared with the parent (i.e., it's not "entropic").

What's wrong with generating some random numbers using the parent's entropy pool before fork and using that as the child's entropy pool?

It does fail if there is not enough entropy.

> An error occurs if the PRNG has not been seeded with enough randomness to ensure an unpredictable byte sequence.

https://www.openssl.org/docs/crypto/RAND_bytes.html

But there is also this:

> Pseudo-random byte sequences generated by RAND_pseudo_bytes() will be unique if they are of sufficient length, but are not necessarily unpredictable.

Was this not one of the things you critisized openssl for?

ie falling back on braindead methods when sane ones failed.

If you don't try to cope with the lack of a /dev/random, you get shit from people. If you try to cope with it, you get shit from people. While I would agree that the fallback entropy gathering is very very hacky and ugly, the difference is that it sure as hell tries harder than OpenSSL ever did. I'm not qualified to say whether the things it uses for entropy are truly any good for it, but it sure looks like it wouldn't be terribly easy to predict all these bits without having compromised the system.

I thought the libressl devs thought it was a mistake to even try to fall back -- the code should use OS-provided random numbers, and if they're not there, give up. If so, I'm a little surprised to hear libressl is trying harder than openssl.

Ideally, that's how it handled. In fact that's how it's handled on OpenBSD. Getentropy either works or you're screwed. As it turns out, there are other systems (hello Linux, etc.) where you don't have such a reliable way to source entropy. I don't know how common it is to encounter this in reality but sadly it looks like it might be quite common indeed, though I hope I'm wrong. See the point about daemons chrooting into /var/empty for example.

You can disable the fallback code with a define, so if your distributors are sure your system should always be able to provide a good entropy source in normal use, they'll flip that switch.

Reply on news.ycombinator.com