4 ms·

In the synopsis, it says "It should not be used [by] Monte Carlo simulations or for other probabilistic sampling applications." Does anyone know why not?

by egwor 12y ago

colanderman 12y ago
Probably because it will be slow and deplete the entropy pool. Statistical sampling doesn't require cryptographically-secure random number generation.
- lomnakkus 12y ago
  "deplete the entropy pool" isn't really a meaningful phrase given the way the Linux /dev/{random,urandom} work. AFAIK /dev/random and /dev/urandom use the same CSPRNG (different instances) which is periodically reseeded with entropy gathered from the system (hw, interrupt timings, etc.), the only difference being that the /dev/random device blocks if an entropy estimator says that there's "too little entropy". It's not that /dev/random has been "depleted" (which is meaningless given how a CSPRNG works), it's just that some entropy estimation code thinks that it might not be a source of perfect entropy/randomness at a particular time. (This practice is pretty questionable, hence the proposed new syscall.)
- AlyssaRowan 12y ago
  This. It'd just be silly to use a slow CSPRNG for that. With this, entropy pool depletion is not really that much of a concern; "urandom reads" from getrandom(2) will have at least one good seed.
bostik 12y ago
At a guess, those applications routinely require large amounts of mostly random (not CSPRNG random) numbers. This syscall returns data from the kernel's entropy pool, presumably at the speed of /dev/urandom. The recommendation is probably a way to say "please don't abuse, and please don't make the kernel spin".
deleted 12y ago
[deleted]
- tptacek 12y ago
  No, you do not ever risk running out of entropy.
kazinator 12y ago
Here are some guesses about the reasoning for this admonition: * Suppose /dev/urandom is not receiving randomness at all, and the Monte Carlo application keeps drawing bits from it like crazy. Then this device is reduced, effectively, to a PRNG. Maybe, as such, it is not a particularly good PRNG; it is not intended to be used that way. It is supposed to take some real entropy bits, and "stretch" them to cover a larger request---but not ridiculously so. * Simulation applications benefit from repeatability: the same seed fetches exactly the same results. You lose that with urandom.
moomin 12y ago
Monte Carlo simulations need to be repeatable. So you can take a seed from entropy, but then you seed your own deterministic RNG. You log the seed so that you can backtest. Doesn't appear many people on this thread are considering such use cases, but it appears the authors have.
ZoFreX 12y ago
I stumbled across a possible answer to this question just now in a discussion regarding a proposed interface for a randomness call where the callee would declare what they are using the randomness for - with Monte Carlo as one of the options. I immediately recalled your comment, so, here is your answer: > I would hope that people would agree there should be a difference between what is needed for a Monte Carlo simulation and other various cryptographic use cases. (I've gotten bug reports from people who insisted on using /dev/urandom for Monte Carlo simulations, and who then complained when it was too slow for their purposes....) https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/msg00125.html https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms...

In the synopsis, it says "It should not be used [by] Monte Carlo simulations or for other probabilistic sampling applications." Does anyone know why not?

by egwor 12y ago

In the synopsis, it says "It should not be used [by] Monte Carlo simulations or for other probabilistic sampling applications." Does anyone know why not?

colanderman 12y ago

Probably because it will be slow and deplete the entropy pool. Statistical sampling doesn't require cryptographically-secure random number generation.

lomnakkus 12y ago
"deplete the entropy pool" isn't really a meaningful phrase given the way the Linux /dev/{random,urandom} work. AFAIK /dev/random and /dev/urandom use the same CSPRNG (different instances) which is periodically reseeded with entropy gathered from the system (hw, interrupt timings, etc.), the only difference being that the /dev/random device blocks if an entropy estimator says that there's "too little entropy". It's not that /dev/random has been "depleted" (which is meaningless given how a CSPRNG works), it's just that some entropy estimation code thinks that it might not be a source of perfect entropy/randomness at a particular time. (This practice is pretty questionable, hence the proposed new syscall.)
AlyssaRowan 12y ago
This. It'd just be silly to use a slow CSPRNG for that. With this, entropy pool depletion is not really that much of a concern; "urandom reads" from getrandom(2) will have at least one good seed.

bostik 12y ago

At a guess, those applications routinely require large amounts of mostly random (not CSPRNG random) numbers. This syscall returns data from the kernel's entropy pool, presumably at the speed of /dev/urandom. The recommendation is probably a way to say "please don't abuse, and please don't make the kernel spin".

deleted 12y ago

[deleted]

tptacek 12y ago
No, you do not ever risk running out of entropy.

kazinator 12y ago

Here are some guesses about the reasoning for this admonition: * Suppose /dev/urandom is not receiving randomness at all, and the Monte Carlo application keeps drawing bits from it like crazy. Then this device is reduced, effectively, to a PRNG. Maybe, as such, it is not a particularly good PRNG; it is not intended to be used that way. It is supposed to take some real entropy bits, and "stretch" them to cover a larger request---but not ridiculously so. * Simulation applications benefit from repeatability: the same seed fetches exactly the same results. You lose that with urandom.

moomin 12y ago

Monte Carlo simulations need to be repeatable. So you can take a seed from entropy, but then you seed your own deterministic RNG. You log the seed so that you can backtest. Doesn't appear many people on this thread are considering such use cases, but it appears the authors have.

ZoFreX 12y ago

I stumbled across a possible answer to this question just now in a discussion regarding a proposed interface for a randomness call where the callee would declare what they are using the randomness for - with Monte Carlo as one of the options. I immediately recalled your comment, so, here is your answer: > I would hope that people would agree there should be a difference between what is needed for a Monte Carlo simulation and other various cryptographic use cases. (I've gotten bug reports from people who insisted on using /dev/urandom for Monte Carlo simulations, and who then complained when it was too slow for their purposes....) https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/msg00125.html https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms...