# [RFC] [VOTE] Vote open for reliable user-land CSPRNG - Thread: https://externals.io/message/84801 - Original archive: https://news-web.php.net/php.internals/84801 - Started by Sammy Kaye Powers on 2015-03-15T03:23:56+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #84801 — Sammy Kaye Powers — 2015-03-15T03:23:56+00:00 URL: https://externals.io/message/84801#84801 A two week discussion period has been held for the reliable user-land CSPRNG RFC to add `random_bytes()` and `random_int()`. The RFC has now been moved into voting. https://wiki.php.net/rfc/easy_userland_csprng There was some discussion of prefixing the function names with `crypto_*()` but there are a few reasons we decided against this: 1) There is a crypto pecl extension, so the pseudo-namespace might cause confusion. 2) We want to work on a fully featured crypto framework for 7.1, and crypto_* is a good prefix for that, so again, we don't want to mix things up. Thanks! Thanks, Sammy Kaye Powers sammyk.me 230 S Clark St #194 Chicago, IL 60604 --- ## #84817 — Matteo Beccati — 2015-03-15T10:29:49+00:00 URL: https://externals.io/message/84801#84817 · In reply to: #84801 > A two week discussion period has been held for the reliable user-land > CSPRNG RFC to add `random_bytes()` and `random_int()`. The RFC has now been > moved into voting. > > https://wiki.php.net/rfc/easy_userland_csprng > > There was some discussion of prefixing the function names with `crypto_*()` > but there are a few reasons we decided against this: > > 1) There is a crypto pecl extension, so the pseudo-namespace might cause > confusion. > 2) We want to work on a fully featured crypto framework for 7.1, and > crypto_* is a good prefix for that, so again, we don't want to mix things > up. 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. 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? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #84824 — padraic.brady@gmail.com — 2015-03-15T13:17:01+00:00 URL: https://externals.io/message/84801#84824 · In reply to: #84817 Hi Matteo, > 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 --- ## #84895 — Leigh — 2015-03-15T20:09:36+00:00 URL: https://externals.io/message/84801#84895 · In reply to: #84817 > > 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. > I wouldn't worry about exhausting the entropy pool, on systems like Linux there is kind of a feedback system where data is mixed back into the pool when you request data. You can pipe /dev/urandom into /dev/null for hours and not suffer any problems. > 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()`. > Of course it would, but that's something that needs to be done through education and via the manual. I understand the concern, but I'm not sure how much I'll worry about it. 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? > The biasing comes from how the result is restricted to a certain range of numbers, it's not related to the quality of the seed. We avoid that by throwing away numbers that would give a biased result, and picking a new number. The poker deck example isn't a brilliant one, because the effects of biasing become more apparent the closer you get to the maximum upper bound, but it's still important to cater for the unlikely-but-possible scenarios. --- ## #84897 — Leigh — 2015-03-15T20:13:17+00:00 URL: https://externals.io/message/84801#84897 · In reply to: #84824 > > 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. > We've deliberately avoided blocking sources for this implementation. > 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. > I should have read your mail before replying, but at least we've said the same thing :) --- ## #84902 — Nikita Popov — 2015-03-15T20:29:53+00:00 URL: https://externals.io/message/84801#84902 · In reply to: #84817 > > > > […] > > [...] > > 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? > The problem is that when using mt_rand - even if you seeded it with a cryptographic random number - you will be able to predict all future random numbers based on the first few. The tiny 32bit seed space can be easily brute forced. MT also allows directly recovering the full internal state from the output, though that requires a relatively large amount of values (624 if not truncated) and as such isn't practical for the Poker case. Nikita --- ## #84951 — Stanislav Malyshev — 2015-03-15T22:56:58+00:00 URL: https://externals.io/message/84801#84951 · In reply to: #84817 Hi! > 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 After reading http://www.2uo.de/myths-about-urandom/, I have hard time seeing how "exhausting entropy pool" would be a real problem.I mean, if running PRNG for "too long" is dangerous, wouldn't we already have much more serious problem with encryption routines based on them which basically do it all the time? Maybe I don't understand the crypto theory under this enough, in which case it may be interesting to read something that explains how that happens and what is the actual problem there. -- Stas Malyshev smalyshev@gmail.com --- ## #84954 — Leigh — 2015-03-15T23:25:14+00:00 URL: https://externals.io/message/84801#84954 · In reply to: #84951 > > if > running PRNG for "too long" is dangerous, wouldn't we already have much > more serious problem with encryption routines based on them which > basically do it all the time? Indeed we would, it's the kind of issue that would get solved pretty quickly (imho). Maybe it was an issue at some point in the past and there's still misinformation out there? Who knows, it certainly isn't an issue today. --- ## #85003 — Matteo Beccati — 2015-03-16T08:40:02+00:00 URL: https://externals.io/message/84801#85003 · In reply to: #84954 Hi, > Indeed we would, it's the kind of issue that would get solved pretty > quickly (imho). Maybe it was an issue at some point in the past and > there's still misinformation out there? Who knows, it certainly isn't an > issue today. thanks everyone for the clarifications! They've been very useful, and not only in the context of the RFC at hand. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #85513 — Pascal Martin — 2015-03-27T20:16:14+00:00 URL: https://externals.io/message/84801#85513 · In reply to: #84801 Le 15/03/2015 04:23, Sammy Kaye Powers a écrit : > A two week discussion period has been held for the reliable user-land > CSPRNG RFC to add `random_bytes()` and `random_int()`. The RFC has now been > moved into voting. Hi, We've talked about this RFC with other people at AFUP and are +1. Thanks! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ --- ## #85528 — Leigh — 2015-03-29T14:08:07+00:00 URL: https://externals.io/message/84801#85528 · In reply to: #85513 Hi all, Voting has now closed on this RFC. The feature has been accepted for PHP 7 with votes of 41 - 0. Thanks to all who participated in the discussion and gave feedback. Regards, Leigh.