← Back to context

Comment by poettering

7 years ago

That "security engineer" appears to imply we use rand() to create crypto keys. I am not sure what he has been smoking. We don't. He appears to be just somebody who doesn't research very well...

And no. We do no generate "keys" from either rand(), nor from RDRAND. We use RDRAND for uuid generation, and rand() for seeding hash tables if there's no better source of entropy. That's all.

Jeezuz christ.

I mean, if we seed hash tables, which options do we have? getrandom()? that either blocks (sometimes very long in virtualized envs) or fails during early boot (and systemd runs in earliest boot being the first process to launch), when the random pool is not initialized. /dev/urandom? That logs loudly about any use when the pool is not initialized. So yeah, we opted to first use RDRAND if available, then fall back to getrandom() with GRND_NONBLOCK, and finally to plain rand() if neither of that works. That has everything we need: doesn't delay boot forever. Doesn't cause log messages about us using a non-initialized pool. It potentially gives us crappy seeds for the hashtable initially, but given that we reseed when we see too many collisions and then getrandom() actually works correctly, we should be fine.

Anyway, you can stick that "security engineer" somewhere, that smug, unresearched bitching on Twitter is just annoying.

Lennart

Filippo Valsorda said nothing about keys. Xe did not mention them at all.

  • The linked bug report showed errors using OpenSSL to generate keys after resume on an AMD platform. It seemed to indicate RDRAND returning an error code instead of entropy.

    Sorry for any confusion.