3
$\begingroup$

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?
$\endgroup$
3
  • $\begingroup$ I know CryptMT, that is a stream cipher/CSPRNG that supports keys up to 2048-bits: github.com/magurosan/CryptMT -- The code doesn't compile with C++ 17, maybe one should ask the author to update to C++ 17 -- In my tests in my AMD Ryzen 5 1400 it has a speed of ~950MiB/s. Despite many attempts cryptanalysis, no one could find a single weakness in this cipher, but there is a little problem, it's patented. $\endgroup$
    – alpominth
    Mar 22, 2023 at 23:57
  • 1
    $\begingroup$ You said /dev/urandom is "slow". How fast was it, and how fast do you need it to be? $\endgroup$
    – knaccc
    Mar 23, 2023 at 0:55
  • $\begingroup$ It's not clear what's wanted: if it's a "pseudo random generator" as in the title, then by definition of that it should be a deterministic function of a seed, implying that reusing the same seed should be possible and would generate the same sequence again. Whereas all the methods and references discussed aim at something that for all practical purposes is a true random generator which aims at making it impossible to generate the same sequence again. $\endgroup$
    – fgrieu
    Mar 23, 2023 at 4:32

1 Answer 1

5
$\begingroup$

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.

$\endgroup$

Your Answer

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

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