Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [VOTE] Vote open for reliable user-land CSPRNG »

[RFC] [VOTE] Vote open for reliable user-land CSPRNG

php.internals

Sammy Kaye Powers

11 years ago
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

Matteo Beccati

11 years ago
On 15/03/2015 04:23, Sammy Kaye Powers wrote:
> 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/

Pádraic Brady

11 years ago
Hi Matteo, On 15 March 2015 at 10:29, Matteo Beccati <php@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

Leigh

11 years ago
On 15 March 2015 at 13:17, Pádraic Brady <padraic.brady@gmail.com> wrote:
> > 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 :)

Leigh

11 years ago
On 15 March 2015 at 10:29, Matteo Beccati <php@beccati.com> wrote:
> > 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.

Nikita Popov

11 years ago
On Sun, Mar 15, 2015 at 11:29 AM, Matteo Beccati <php@beccati.com> wrote:
> On 15/03/2015 04:23, Sammy Kaye Powers wrote: > >> 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. >> > > [...] > > 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

Stas Malyshev

11 years ago
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

Leigh

11 years ago
On 15 March 2015 at 22:56, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> > 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.

Matteo Beccati

11 years ago
Hi, On 16/03/2015 00:25, Leigh wrote:
> 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/

Pascal MARTIN

11 years ago
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/

Leigh

11 years ago
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.