6 ms·

Is there a good random library that's not the giant ball of death that's OpenSSL?

viraptor 11y ago
Depends on why you want to use a random number generating library. What are your requirements and specifically what are your requirements that aren't satisfied with the system's csprng. Once you have that defined, you can start looking at what algorithms you want and from there what libraries implement it. Edit: or to put another way, first define what is it that linux's getrandom() and /dev/urandom doesn't provide you.
- astrodust 11y ago
  This talk about C++ and rand being harmful is quite educational: https://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful https://channel9.msdn.com/Events/GoingNative/2013/rand-Consi... What it points out is that even a good random number generator can be used incorrectly, and without the right tools your efforts to produce truly random numbers are doomed from the start. C++ has an embarrassing wealth of random number generators. The Ruby core has almost nothing that can measure up to that, yet it seems like a huge oversight. I like that C++ has a generator for many different use cases, they all have their reason for being there, but Ruby has a singular one with unknown properties. Porting over what C++ has and making a proper Random library for Ruby would make a lot of sense here.
  - tptacek 11y ago
    None of those C++ RNGs are suitable for cryptography. The answer for C++ CSPRNGs is, like in every other language, to use /dev/urandom. Multiple CSPRNGs just mean multiple single points of failure.
    - astrodust 11y ago
      Not every random number generator has to be cryptographically secure. Sometimes they just need to be properly random.
yarou 11y ago
I've used Mersenne Twister[0] in the past. [0] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html If you're talking about an RNG library for cryptographic purposes, then it depends on your use case.
- viraptor 11y ago
  That one needs manual seeding too, which may lead to more issues.
- tptacek 11y ago
  It does not depend on your use case. The answer, in all cases, is just to use /dev/urandom.
  - sibrahim 11y ago
    I had a rather specialized case where it was the pragmatic choice (note, not technically required): running a lottery with potentially litigious losers. If you used a CSPRNG with a seed space smaller than the set of possible lottery outcomes, losers could argue (misleadingly, since we still couldn't feasibly bias the result) that not all outcomes were equally probable and try to get the results thrown out. That is, the fact that there are widespread misconceptions about /dev/random can very rarely be a reason to use it :P However, I agree that the rule is that you should just use /dev/urandom.
    - netheril96 11y ago
      Then what CSPRNG do you use? Any that has seeds larger than 256-bit?
      - sibrahim 11y ago
        Anything that reseeds during operation can qualify. In fact, if the CSPRNG's internal state isn't large enough, you need to periodically reseed or face the same objection. But a CSPRNG which you need to explicitly seed with random bits as big as your output isn't providing much value (simply whitening) since generating the seed is the same problem you had before adding the CSPRNG. So you end up looking at a TRNG.
ryuuchin 11y ago
As others have said it depends on your needs[6] and whether or not it has to be a CSPRNG (cryptographically secure). Since you mentioned OpenSSL I'll assume that in this context we are talking about a CSPRNG. The short answer is to just use the OS provided one if available. Linux has /dev/urandom[1] and the getrandom[2] syscall and Windows has RtlGenRandom[3][4] (there's also CryptGenRandom on Windows which is the "official" version but is more awkward to use since it requires a CSP context to use). On Windows this uses AES-256 in CTR mode as specified in NIST 800-90. Outside of those (if for whatever reason[6] you're not satisfied with just using what the OS provides you) you can also take a look at how BoringSSL does things[5] (and LibreSSL although I'm less familiar with it). It uses a ChaCha20 instance to filter rdrand output (if supported, otherwise it just uses the system CSPRNG directly). The system CSPRNG is used to key the ChaCha20 instance and then for every call to RAND_bytes it uses rdrand output equal to however many bytes you requested and that gets essentially filtered through the ChaCha20 instance. It's fast and pretty simple. I found the code to be pretty easy to understand[5]. I believe LibreSSL does something similar with ChaCha20 although I'm not sure it uses rdrand. I think there should be a pretty good reason if you're choosing not to use what the OS provides for you. tl;dr Just use /dev/urandom (or the getrandom syscall) on Linux and RtlGenRandom on Windows. [1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ http://sockpuppet.org/blog/2014/02/25/safely-generate-random... [2] http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [4] https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/windows.c#26 https://boringssl.googlesource.com/boringssl/+/master/crypto... (RtlGenRandom requires slightly special definitions to work). [5] https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/rand.c https://boringssl.googlesource.com/boringssl/+/master/crypto... [6] There really isn't a "depending on your use case" decision to make. /dev/urandom (or RtlGenRandom) is the correct choice for all cases. With that being said there may be two small caviats to that. Whether or not it has to be a CSPRNG and whether or not /dev/urandom (or RtlGenRandom) can provide the throughput which you require. In certain cases you may have to expand /dev/urandom with something like ChaCha20 if /dev/urandom is too slow (the BoringSSL devs mentioned that for AES-CBC IV generation on servers this can sometimes be the case, see [5] for the BoringSSL implementation).
forgotpwtomain 11y ago
ISAAC (http://burtleburtle.net/bob/rand/isaacafa.html http://burtleburtle.net/bob/rand/isaacafa.html) for a CSPRNG. But what is your use-case for something non-standard? Just use /dev/urandom
- derefr 11y ago
  How about, backing the equivalent of /dev/urandom for a unikernel OS?
- dchest 11y ago
  No, no, no, don't use ISAAC.
  - forgotpwtomain 11y ago
    Do you have a citation you can provide? I don't know of any research that has shown a significant weakness in ISAAC.
    - dchest 11y ago
      Why would you use a PRNG with unknown cryptographic properties, not designed by a cryptographer, as opposed to one of the NIST's DRBG or a good stream cipher, such as ChaCha? Weakness: https://eprint.iacr.org/2006/438 https://eprint.iacr.org/2006/438 — "huge subsets of internal states which induce a strongly non-uniform distribution in the 8192 first bits produced" Finally, why is deterministic PRNG suggested as a replacement for OpenSSL's random number generator? In general, the advice to write your own userspace PRNG replacement for OpenSSL is not a good advice, because many people are not competent enough to do it.
      - forgotpwtomain 11y ago
        > as opposed to one of the NIST's DRBG I certainly wouldn't go anywhere near another NIST DRBG.. > https://eprint.iacr.org/2006/438 https://eprint.iacr.org/2006/438 From my brief understanding Aumasson's paper uses a different seeding routine from the example provided in the c implementation which allows the weaker states to be produced - indeed it's mentioned on the author's website. > Finally, why is deterministic PRNG suggested as a replacement for OpenSSL's random number generator? In general, the advice to write your own userspace PRNG replacement for OpenSSL is not a good advice, because many people are not competent enough to do it. If you read my above post I clearly do not suggest this.

Depends on why you want to use a random number generating library. What are your requirements and specifically what are your requirements that aren't satisfied with the system's csprng. Once you have that defined, you can start looking at what algorithms you want and from there what libraries implement it. Edit: or to put another way, first define what is it that linux's getrandom() and /dev/urandom doesn't provide you.

astrodust 11y ago
This talk about C++ and rand being harmful is quite educational: https://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful https://channel9.msdn.com/Events/GoingNative/2013/rand-Consi... What it points out is that even a good random number generator can be used incorrectly, and without the right tools your efforts to produce truly random numbers are doomed from the start. C++ has an embarrassing wealth of random number generators. The Ruby core has almost nothing that can measure up to that, yet it seems like a huge oversight. I like that C++ has a generator for many different use cases, they all have their reason for being there, but Ruby has a singular one with unknown properties. Porting over what C++ has and making a proper Random library for Ruby would make a lot of sense here.
- tptacek 11y ago
  None of those C++ RNGs are suitable for cryptography. The answer for C++ CSPRNGs is, like in every other language, to use /dev/urandom. Multiple CSPRNGs just mean multiple single points of failure.
  - astrodust 11y ago
    Not every random number generator has to be cryptographically secure. Sometimes they just need to be properly random.

yarou 11y ago

I've used Mersenne Twister[0] in the past. [0] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html If you're talking about an RNG library for cryptographic purposes, then it depends on your use case.

viraptor 11y ago
That one needs manual seeding too, which may lead to more issues.
tptacek 11y ago
It does not depend on your use case. The answer, in all cases, is just to use /dev/urandom.
- sibrahim 11y ago
  I had a rather specialized case where it was the pragmatic choice (note, not technically required): running a lottery with potentially litigious losers. If you used a CSPRNG with a seed space smaller than the set of possible lottery outcomes, losers could argue (misleadingly, since we still couldn't feasibly bias the result) that not all outcomes were equally probable and try to get the results thrown out. That is, the fact that there are widespread misconceptions about /dev/random can very rarely be a reason to use it :P However, I agree that the rule is that you should just use /dev/urandom.
  - netheril96 11y ago
    Then what CSPRNG do you use? Any that has seeds larger than 256-bit?
    - sibrahim 11y ago
      Anything that reseeds during operation can qualify. In fact, if the CSPRNG's internal state isn't large enough, you need to periodically reseed or face the same objection. But a CSPRNG which you need to explicitly seed with random bits as big as your output isn't providing much value (simply whitening) since generating the seed is the same problem you had before adding the CSPRNG. So you end up looking at a TRNG.

ryuuchin 11y ago

As others have said it depends on your needs[6] and whether or not it has to be a CSPRNG (cryptographically secure). Since you mentioned OpenSSL I'll assume that in this context we are talking about a CSPRNG. The short answer is to just use the OS provided one if available. Linux has /dev/urandom[1] and the getrandom[2] syscall and Windows has RtlGenRandom[3][4] (there's also CryptGenRandom on Windows which is the "official" version but is more awkward to use since it requires a CSP context to use). On Windows this uses AES-256 in CTR mode as specified in NIST 800-90. Outside of those (if for whatever reason[6] you're not satisfied with just using what the OS provides you) you can also take a look at how BoringSSL does things[5] (and LibreSSL although I'm less familiar with it). It uses a ChaCha20 instance to filter rdrand output (if supported, otherwise it just uses the system CSPRNG directly). The system CSPRNG is used to key the ChaCha20 instance and then for every call to RAND_bytes it uses rdrand output equal to however many bytes you requested and that gets essentially filtered through the ChaCha20 instance. It's fast and pretty simple. I found the code to be pretty easy to understand[5]. I believe LibreSSL does something similar with ChaCha20 although I'm not sure it uses rdrand. I think there should be a pretty good reason if you're choosing not to use what the OS provides for you. tl;dr Just use /dev/urandom (or the getrandom syscall) on Linux and RtlGenRandom on Windows. [1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ http://sockpuppet.org/blog/2014/02/25/safely-generate-random... [2] http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [4] https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/windows.c#26 https://boringssl.googlesource.com/boringssl/+/master/crypto... (RtlGenRandom requires slightly special definitions to work). [5] https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/rand.c https://boringssl.googlesource.com/boringssl/+/master/crypto... [6] There really isn't a "depending on your use case" decision to make. /dev/urandom (or RtlGenRandom) is the correct choice for all cases. With that being said there may be two small caviats to that. Whether or not it has to be a CSPRNG and whether or not /dev/urandom (or RtlGenRandom) can provide the throughput which you require. In certain cases you may have to expand /dev/urandom with something like ChaCha20 if /dev/urandom is too slow (the BoringSSL devs mentioned that for AES-CBC IV generation on servers this can sometimes be the case, see [5] for the BoringSSL implementation).

forgotpwtomain 11y ago

ISAAC (http://burtleburtle.net/bob/rand/isaacafa.html http://burtleburtle.net/bob/rand/isaacafa.html) for a CSPRNG. But what is your use-case for something non-standard? Just use /dev/urandom

derefr 11y ago
How about, backing the equivalent of /dev/urandom for a unikernel OS?
dchest 11y ago
No, no, no, don't use ISAAC.
- forgotpwtomain 11y ago
  Do you have a citation you can provide? I don't know of any research that has shown a significant weakness in ISAAC.
  - dchest 11y ago
    Why would you use a PRNG with unknown cryptographic properties, not designed by a cryptographer, as opposed to one of the NIST's DRBG or a good stream cipher, such as ChaCha? Weakness: https://eprint.iacr.org/2006/438 https://eprint.iacr.org/2006/438 — "huge subsets of internal states which induce a strongly non-uniform distribution in the 8192 first bits produced" Finally, why is deterministic PRNG suggested as a replacement for OpenSSL's random number generator? In general, the advice to write your own userspace PRNG replacement for OpenSSL is not a good advice, because many people are not competent enough to do it.
    - forgotpwtomain 11y ago
      > as opposed to one of the NIST's DRBG I certainly wouldn't go anywhere near another NIST DRBG.. > https://eprint.iacr.org/2006/438 https://eprint.iacr.org/2006/438 From my brief understanding Aumasson's paper uses a different seeding routine from the example provided in the c implementation which allows the weaker states to be produced - indeed it's mentioned on the author's website. > Finally, why is deterministic PRNG suggested as a replacement for OpenSSL's random number generator? In general, the advice to write your own userspace PRNG replacement for OpenSSL is not a good advice, because many people are not competent enough to do it. If you read my above post I clearly do not suggest this.