Fast and secure pseudo random generator with Linux tools

The conventional and simple wisdom is to combine head with /dev/urandom to create the amount of pseudo-random data that is needed. But that is slow.

I found a faster method - cryptsetup FAQ suggests to use its mechanism.
See 2.19 at:
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions

But the issue with this method is that root privileges are required for the mapping by cryptsetup (dm-crypt).

So, I need a similar method which won't require root privileges.

Some StackExchange posts suggested openssl encoding with -aes-256-ctr:
https://serverfault.com/a/415962 https://serverfault.com/a/714412

But I don't know whether CTR is really preferred in this case over CBC.
Won't CTR break the pseudo-randomness of the data?

Another approach was to use openssl rand - see post:
https://serverfault.com/a/146996

The manual page of openssl rand is unclear (for me) regarding its method.
See:

The random bytes are generated using the RAND_bytes(3) function, which provides a security level of 256 bits, provided it managed to seed itself successfully from a trusted operating system entropy source. Otherwise, the command will fail with a nonzero error code. For more details, see RAND_bytes(3), RAND(7), and EVP_RAND(7).

Yet man RAND_bytes is nonexistent.

Among the last ones above, is there a strong preference in terms of the strength of the pseudo-randomness ?
Meaning, either:

1. openssl enc -aes-256-ctr
2. openssl enc -aes-256-cbc
3. openssl rand
4. Other?

The Linux /dev/random and /dev/urandom have been upgraded significantly since the posting of the answers that propose AES-CTR or CBC. They are generally pointing to the same random number implementations and they are unlikely to block.

AES-CTR or CBC will only use 128, 192 or 256 bits of data, and you haven't explained where you'd get the entropy for that. Furthermore, these algorithms won't reseed. I'd definitely not assume them to be as good as a DRBG. That said, AES-CTR is considered a CSPRNG in most definitions - until the nonce runs out of course. In some ways I don't like that there is literally zero chance of a 16 byte block ever repeating, but the chance of that happening is negligible anyway.

The OpenSSL openssl rand is based on a large state and a cryptographic hash (MD5 by default, but used in a loop). You can find the best documentation on their Wiki but it lacks a clear definition. You can find the implementation here. During command line use I guess it is unlikely to reseed. I'd certainly rate it above AES in a mode of operation due to the large state size. However, in the end, I'd only use it if /dev/urandom is too slow.

I'd advice against going to use root privs for this kind of randomness; the security implications of that is larger than any gain; DRBG's can run fine in user mode after all.

Note that AES-CTR and CBC need a random key, which must be generated using a random number generator. That also goes for openssl rand which is seeded by the system's random number generator. So if you're on a Linux system, it will basically use /dev/random or /dev/urandom as to seed itself.

As another note: on many modern processors there may be a /dev/hwrng that points directly to an onboard PRNG on newer Intel and AMD processors (amongst others) called RDRAND. If that device is present it may provide you with a fast RNG that is directly seeded by a entropy source in the processor itself. If it is secure mainly depends on the debate if it hasn't been deliberately altered by the NSA; it's hard to test the output or the processor after all.