4 ms·

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.htm

by yarou 10y 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 10y ago
That one needs manual seeding too, which may lead to more issues.
tptacek 10y ago
It does not depend on your use case. The answer, in all cases, is just to use /dev/urandom.
- sibrahim 10y 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 10y ago
    Then what CSPRNG do you use? Any that has seeds larger than 256-bit?
    - sibrahim 10y 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.
  - Thiez 10y ago
    Why not use a hardware rng in that case? Seems a lot safer if you have to deal with litigious people.
    - sibrahim 10y ago
      We did, in a way. One of the sources used was random.org (uses radio receivers tuned to static from atmospheric noise: hardware RNG as a service). I also had less than 3 weeks to take it from proposal to production. Combining two independent sources obtained by different people and using a cryptographic commitment scheme ensured that 1) no one person could fix the results or make it nonrandom (protection against Eddie Tipton-style attacks), 2) if at least one of the independent sources was random, the result would be.
- lmm 10y ago
  Are there not cases where blocking if there is insufficient entropy is the correct thing to do? Particularly if we're talking about important random numbers like long-lived private keys.
  - kevhito 10y ago
    No, there are not [1]. [1]: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
    - lmm 10y ago
      It must be possible for a computer to simply not have an adequate supply of randomness though, no? Sure, urandom will use hardware sources of randomness if they're available - but what if they're not?
      - tptacek 10y ago
        No, this is a misconception. Once the LRNG is seeded, it can generate a more or less unbounded amount of high-quality random bytes from that seed. Entropy can't be "depleted".
        lmm 10y ago
        Then how can a 4096-byte key be meaningfully safer than a 1024-byte key? Couldn't you just use the 1024-byte key to seed a RNG, generate a 4096-byte key from that, and have 4096-byte safety? (Also what if the linux RNG isn't seeded e.g. in a VM scenario? Or is the answer just "don't do that"?)
0x0 10y ago
Have you seen the php mt_rand cracker? http://www.openwall.com/php_mt_seed/ http://www.openwall.com/php_mt_seed/
PeCaN 10y ago
mt19937 (or preferably SFMT¹) is a great library (and fine for cryptographic purposes if you have a sufficiently random entropy source with which to seed it, and reseed it frequently from your entropy source), but you still have to seed it somehow which is where /dev/(u)random comes in. So it really doesn't solve anything. -- ¹ http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.h...

by yarou 10y ago

viraptor 10y ago

That one needs manual seeding too, which may lead to more issues.

tptacek 10y ago

It does not depend on your use case. The answer, in all cases, is just to use /dev/urandom.

sibrahim 10y 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 10y ago
  Then what CSPRNG do you use? Any that has seeds larger than 256-bit?
  - sibrahim 10y 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.
- Thiez 10y ago
  Why not use a hardware rng in that case? Seems a lot safer if you have to deal with litigious people.
  - sibrahim 10y ago
    We did, in a way. One of the sources used was random.org (uses radio receivers tuned to static from atmospheric noise: hardware RNG as a service). I also had less than 3 weeks to take it from proposal to production. Combining two independent sources obtained by different people and using a cryptographic commitment scheme ensured that 1) no one person could fix the results or make it nonrandom (protection against Eddie Tipton-style attacks), 2) if at least one of the independent sources was random, the result would be.
lmm 10y ago
Are there not cases where blocking if there is insufficient entropy is the correct thing to do? Particularly if we're talking about important random numbers like long-lived private keys.
- kevhito 10y ago
  No, there are not [1]. [1]: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
  - lmm 10y ago
    It must be possible for a computer to simply not have an adequate supply of randomness though, no? Sure, urandom will use hardware sources of randomness if they're available - but what if they're not?
    - tptacek 10y ago
      No, this is a misconception. Once the LRNG is seeded, it can generate a more or less unbounded amount of high-quality random bytes from that seed. Entropy can't be "depleted".
      - lmm 10y ago
        Then how can a 4096-byte key be meaningfully safer than a 1024-byte key? Couldn't you just use the 1024-byte key to seed a RNG, generate a 4096-byte key from that, and have 4096-byte safety? (Also what if the linux RNG isn't seeded e.g. in a VM scenario? Or is the answer just "don't do that"?)

0x0 10y ago

Have you seen the php mt_rand cracker? http://www.openwall.com/php_mt_seed/ http://www.openwall.com/php_mt_seed/

PeCaN 10y ago

mt19937 (or preferably SFMT¹) is a great library (and fine for cryptographic purposes if you have a sufficiently random entropy source with which to seed it, and reseed it frequently from your entropy source), but you still have to seed it somehow which is where /dev/(u)random comes in. So it really doesn't solve anything. -- ¹ http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.h...