Hi Matteo, On 15 March 2015 at 10:29, Matteo Beccati <p...@beccati.com> wrote: > Disclaimer: I do know a little about security, but I am not a crypto-expert > by any means. If I'm saying something silly, just let me know ;) > > I want to vote yes, but naming is something that scares me a bit. Without > any indication that it's CSPRNG, people might start using it even when > unnecessary, and I'd be worried about potential negative effects, such as > exhausting the entropy pool. It's probably more of a documentation problem, > but we know many won't read the docs and a "hint" in the function name could > help guiding users.
Were folk to use random_int() by default, it would be actually be considerably better than the situation today where many reach for mt_rand() without really considering the use case. Using a strong source of ints instead of a weak source still ends up with you getting the requested ints. There's no downside unless the source is blocking. Using the weak source over a strong source will also get you ints, but without knowing the use, it has the immediate downside risk of being from a weak source which shouldn't be used for anything requiring strong randomness. So random_int() really is the best first default option to go for when in doubt, with some careful consideration before switching to mt_rand(). As for exhausting the entropy pool, this is something of a misconception. The sources in the RFC are pseudorandom generators which won't exhaust the entropy pool by design. > For example, it would be overkill to use random_int() to randomly pick the > content of a boxes at each reload of a web page, but if what I need is a > *random int*, then random_int() seems a far better choice than some obscure > rand() or mt_rand(). > > Or in the poker deck example, wouldn't it be enough just to seed mt_srand > with a crypto-secure number to remove the biasing and using mt_rand to > shuffle the deck? In essence, this is what the functions are already providing an interface to: systems which take a truly random seed and output pseudorandom values. The difference is that the underlying system is designed to be cryptographically secure (for most uses). mt_rand(), on the other hand, is not. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
