25
$\begingroup$

I'm wondering if the openssl rand command produces cryptographically secure random bytes. For example when in need for a random password or token:

openssl rand -hex 32

The man page unfortunately does neither state it's cryptographically secure, nor that it's not.

On the one hand, I think this is openssl, its sole purpose is to do cryptography. On the other hand, the man page states something about reading and writing seed data instead of directly querying a CSPRNG.

So it is somewhat unclear for the end user. Does someone know?

$\endgroup$

1 Answer 1

20
$\begingroup$

Yes, it is cryptographically secure, pseudo random output, seeded by retrieving secure random data from the operating system.

If it is random or not depends on the fact if the OS RNG is random. This is usually the case on normal desktops, but you'd better be sure for e.g. limited embedded systems. If no truly random data can be retrieved - according to RAND_bytes - then rand will exit with an error. In a similar note: you may need to include the client toolset on VM's to retrieve true random data, especially when duplicating environments.

Added note: Of course you are dependent on the implementation. Famously OpenSSL was broken for Debian because a maintainer ran a program to find memory errors and disabled all entropy sources rather than the one that was (deliberately) failing the property that no uninitialized memory should be used. So it is of importance to review security reports and keep your system up-to-date / on long term support.


Any random source that you add using -rand [file][:file]* is used as additional seed data - in other words, the output will always be random, even if you supply the same seed.

As the pseudo random generator provided by OpenSSL generally runs in the application space on the main thread, it may be faster than asking a lot of data from /dev/urandom. But to be honest, most of the time using /dev/urandom suffices (and current implementations are pretty fast as well).


You can see that it is random when you look at the link to the RAND_bytes manual page which is the function that lies behind command line rand and is linked to from the manual page (in the "see also section, but yeah"):

RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf. An error occurs if the PRNG has not been seeded with enough randomness to ensure an unpredictable byte sequence.

That RAND_bytes() is used can be found in the source file for the rand command, rand.c, so yes, this is indeed the function that is called.

$\endgroup$
6
  • $\begingroup$ Please clarify that openssl rand uses a time based (so non-deterministic) seed? $\endgroup$
    – samthebest
    Aug 21, 2019 at 14:04
  • $\begingroup$ It doesn't, certainly not as only seed. So why would I clarify that? $\endgroup$
    – Maarten Bodewes
    Aug 21, 2019 at 15:50
  • $\begingroup$ So if you ran this once, then wiped your computer and reinstalled it, then ran it again, it would give the same output? Or different output? $\endgroup$
    – samthebest
    Aug 22, 2019 at 13:02
  • 4
    $\begingroup$ No, of course it would not generate the same stream or sufficiently large part of a stream. Generally the main entropy source of OpenSSL is the operating system's random generator. So as long as that is random you're secure. This can still be an issue for e.g. Virtual Machines, which may not have direct access to hardware (HDD timings, network cards, etc.) to retrieve initial entropy. Hence it is often wise to install the utilities for client VM's. Newer Intel and AMD processors actually have an entropy source, although AMD's version in Zen 2 famously didn't survive suspend & resume. $\endgroup$
    – Maarten Bodewes
    Aug 22, 2019 at 13:49
  • 4
    $\begingroup$ No good secure random generator depends on current time alone. It cannot be because any attacker just guessing the time would be able to generate the same stream. $\endgroup$
    – Maarten Bodewes
    Aug 22, 2019 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.