on the prng behind random.random()
On Tue, Nov 20, 2018 at 10:51 AM Robert Girault <r at dev.null> wrote:
> If you're just writing a toy software, even K&R PRNG works just fine.
> If you're writing a weather simulation, I suppose you need real
> random-like properties and still need your generator to be reproducible.
> If you're using random Quicksort, you do need unpredictability and
> reproducibility. If you're writing a crypto application, then you need
> something way stronger. We need all of them. But mt19937 is now useful
> only in toy software.
I disagree. Yes, in a crypto-sensitive situation, you can't depend on
the Twister... but you shouldn't be relying on *any* PRNG for that.
There are plenty of situations where you need something unpredictable
but it doesn't have to be THAT safe. Your example of picking a random
pivot for quicksort is a perfect example. Let's suppose I am sorting
by that method... how are you going to get 624 consecutive outputs? If
you can provide a custom comparison function, you can DOS the search
just by making that inefficient. If you can't, how are you going to
reconstruct the randomness? Is this REALLY a viable attack vector?
It's different if, say, you're operating a virtual casino, and letting
people watch the roulette wheel spins. (Though even then,
reconstructing the twister's state from a series of 1-in-38 results
isn't going to be trivial.) But it's overly paranoid to say that every
single PRNG needs to be cryptographically secure.