# unify entropy source for all php related functions

- Thread: https://externals.io/message/72374
- Original archive: https://news-web.php.net/php.internals/72374
- Started by Pierre Joye on 2014-02-07T11:25:45+00:00
- Messages: 19
- 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

---

## #72374 — Pierre Joye — 2014-02-07T11:25:45+00:00

URL: https://externals.io/message/72374#72374

hi,

There are a lot of additions and discussions about entropy source and
(P)RNG lately.

PHP already has a ini setting to define a strong entropy source for
the session module, which defaults to urandom or arandom.

I would like to create two settings to unify the entropy source
accross php functions. That includes mcrypt, new password APIs,
session, LCG, etc.

Something along this line:

random.entropy_strong_source (/dev/(u|a)random etc.)
random.entropy_crypto_source (/dev/random etc.)

I am not willing to propose new RNG functions or extensions for 5.6 as
we have way too little time to actually discuss its design and APIs.
However having these settings unified and documented would be a good
step forward already.

Thoughts?

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #72377 — Tjerk Meesters — 2014-02-07T11:42:46+00:00

URL: https://externals.io/message/72374#72377 · In reply to: #72374

> hi,
>
> There are a lot of additions and discussions about entropy source and
> (P)RNG lately.
>
> PHP already has a ini setting to define a strong entropy source for
> the session module, which defaults to urandom or arandom.
>
> I would like to create two settings to unify the entropy source
> accross php functions. That includes mcrypt, new password APIs,
> session, LCG, etc.
>
> Something along this line:
>
> random.entropy_strong_source (/dev/(u|a)random etc.)
> random.entropy_crypto_source (/dev/random etc.)
>
> I am not willing to propose new RNG functions or extensions for 5.6 as
> we have way too little time to actually discuss its design and APIs.
> However having these settings unified and documented would be a good
> step forward already.
>

Here's a wild idea; assuming for a second that `rand()` is actually fed by
a proper entropy source, are there BC implications if we did that? :)

Alternatively, we would be looking at dedicated `random_` functions that
provide a similar functionality and end up with an API such as:

int random_integer($min, $max)
string random_string($length, $crypto_safe)

etc...


>
> Thoughts?
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> 
> 
>
>


-- 
--
Tjerk

---

## #72378 — Pierre Joye — 2014-02-07T11:46:15+00:00

URL: https://externals.io/message/72374#72378 · In reply to: #72377

On Fri, Feb 7, 2014 at 12:42 PM, Tjerk Meesters
<tjerk.meesters@gmail.com> wrote:

> Here's a wild idea; assuming for a second that `rand()` is actually fed by a
> proper entropy source, are there BC implications if we did that? :)
>
> Alternatively, we would be looking at dedicated `random_` functions that
> provide a similar functionality and end up with an API such as:
>
> int random_integer($min, $max)
> string random_string($length, $crypto_safe)
>
> etc...

A good PRNG APIs will provides various weak implementations as well as
strong and crypto safe backend.

However, I would really try to only focus on the unification for the
entropy sources setting. We do not have the time to actually do a good
job/discussion/design about what would be a good PNRG APIs and
features, for 5.6.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #72379 — padraic.brady@gmail.com — 2014-02-07T11:53:00+00:00

URL: https://externals.io/message/72374#72379 · In reply to: #72374

Hi Pierre,


> hi,
>
> There are a lot of additions and discussions about entropy source and
> (P)RNG lately.
>
> PHP already has a ini setting to define a strong entropy source for
> the session module, which defaults to urandom or arandom.
>
> I would like to create two settings to unify the entropy source
> accross php functions. That includes mcrypt, new password APIs,
> session, LCG, etc.
>
> Something along this line:
>
> random.entropy_strong_source (/dev/(u|a)random etc.)
> random.entropy_crypto_source (/dev/random etc.)

In principle, that makes a lot of sense. It beats wondering what each
different function is using under the covers and may even simplify
userland code a bit (and reduce some file checking if it can be relied
upon).

> I am not willing to propose new RNG functions or extensions for 5.6 as
> we have way too little time to actually discuss its design and APIs.
> However having these settings unified and documented would be a good
> step forward already.

I think the end goal should be unification with some generalised API.
At the moment we have `mt_rand()`, `lcg_value()`,
 `openssl_random_pseudo_bytes()`, mcrypt_create_iv() and then the file
read approaches. They all have uses, but they sit in different places
and extensions and it’s not always clear what each is best at. I agree
that this would take a lot of time to work through.

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

---

## #72380 — Pierre Joye — 2014-02-07T11:55:10+00:00

URL: https://externals.io/message/72374#72380 · In reply to: #72379

> In principle, that makes a lot of sense. It beats wondering what each
> different function is using under the covers and may even simplify
> userland code a bit (and reduce some file checking if it can be relied
> upon).

Yes, both effects are part of the idea. It is useful in userland as
well as one can simply fopen one of them without worrying about it.

> > […]
>
> I think the end goal should be unification with some generalised API.
> At the moment we have `mt_rand()`, `lcg_value()`,
> `openssl_random_pseudo_bytes()`, mcrypt_create_iv() and then the file
> read approaches. They all have uses, but they sit in different places
> and extensions and it’s not always clear what each is best at. I agree
> that this would take a lot of time to work through.

Yes, something we can think about targeting 6 and cleanup all this mess :)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #72381 — Nikita Popov — 2014-02-07T12:13:59+00:00

URL: https://externals.io/message/72374#72381 · In reply to: #72374

> hi,
>
> There are a lot of additions and discussions about entropy source and
> (P)RNG lately.
>
> PHP already has a ini setting to define a strong entropy source for
> the session module, which defaults to urandom or arandom.
>
> I would like to create two settings to unify the entropy source
> accross php functions. That includes mcrypt, new password APIs,
> session, LCG, etc.
>
> Something along this line:
>
> random.entropy_strong_source (/dev/(u|a)random etc.)
> random.entropy_crypto_source (/dev/random etc.)
>
> I am not willing to propose new RNG functions or extensions for 5.6 as
> we have way too little time to actually discuss its design and APIs.
> However having these settings unified and documented would be a good
> step forward already.
>

I'm not sure I understand this proposal and/or its purpose. Different
applications have different requirements on the strength of the random
number generator. As such this is something that needs to be specified on
every use, rather than a (global) ini setting.

If your proposal is to have different different "categories" of randomness
(the names indicate "strong" and "crypto"), then I see little point in
having inis for this, rather than letting PHP choose an appropriate source
(from that category) that is available on the system. Also, if you want to
introduce such categories, you should also clarify how they will be used
with the individual functions. Does that mean mcrypt_create_iv will have
additional MCRYPT_STRONG and MCRYPT_CRYPTO options that will then use the
source specified by the respective inis? Will the same also be added to
openssl_pseudo_random_bytes as a (third) parameter?

And what do you mean by LCG? Do you mean the `lcg_value()` generator for
floating point numbers? I don't see how that function is supposed to make
use of these options. After all, the name already says that it uses a
linear congruential generator, so that should be what it uses. Or do you
mean to use the specified randomness source for the seed? That doesn't make
a lot of sense to me, as you'd be sticking a strong random seed into a
very, very weak prng.

I feel like these ini settings make things only more confusing. I'd much
more appreciate the introduction of a function for generating random bytes
in the standard library, that supersedes the individual extension functions.

Nikita

---

## #72382 — Pierre Joye — 2014-02-07T12:23:48+00:00

URL: https://externals.io/message/72374#72382 · In reply to: #72381

> I'm not sure I understand this proposal and/or its purpose. Different
> applications have different requirements on the strength of the random
> number generator. As such this is something that needs to be specified on
> every use, rather than a (global) ini setting.

Not for this exact feature.

Example:
session uses an entropy source, u or a random by default or a user
defined source
mcrypt uses them as well, depending on the argument
The new password API tries to open /dev/urandom (and only!) and fall
back to `rand()`, which is quite bad.

Basically, they all have the same need for this exact feature.

What I propose is to add two settings because there is two needs right
now (and for quite some time actually):

- strong
   good enough for password generation and the likes

- crypto safe
   key generations and other cryptography related operations (usually
blocking op too btw)


> If your proposal is to have different different "categories" of randomness
> (the names indicate "strong" and "crypto"), then I see little point in
> having inis for this, rather than letting PHP choose an appropriate source
> (from that category) that is available on the system. Also, if you want to
> introduce such categories, you should also clarify how they will be used
> with the individual functions. Does that mean mcrypt_create_iv will have
> additional MCRYPT_STRONG and MCRYPT_CRYPTO options that will then use the
> source specified by the respective inis? Will the same also be added to
> openssl_pseudo_random_bytes as a (third) parameter?


No, they know which to use. And they already do it internally, hard
coded. The only problem is that they all do their little receipts and
there is no way to actually tell them to use a specific source for a
specific need.


> I feel like these ini settings make things only more confusing. I'd much
> more appreciate the introduction of a function for generating random bytes
> in the standard library, that supersedes the individual extension functions.

It makes things more clear, as you will then know exactly which source
is used for what. It is impossible now and you cannot change or
configure them. Making impossible or harder than it should to anyone
to setup a custom entropy source (for shared hosting or apps needing
more entropy data).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #72383 — Pierre Joye — 2014-02-07T12:29:53+00:00

URL: https://externals.io/message/72374#72383 · In reply to: #72382

> 
>
> > […]
>
> Not for this exact feature.

To clarify my point, I forgot to mention something.

This setting is not about changing any existing function behavior or
how a given argument (using one of the dozen constants) behave, nor
what a given argument will use as source. Each argument defines an
entropy source which fits in one of the two propose settings. That's
why these settings only allow one to define what will be used instead
of hardcode /dev/random, /dev/urandom or /dev/arandom. Especially for
the implementations where only one is used without any chance to work
around it (besides ugly symlink and the likes).

---

## #72385 — Nikita Popov — 2014-02-07T12:58:31+00:00

URL: https://externals.io/message/72374#72385 · In reply to: #72374

> hi,
>
> There are a lot of additions and discussions about entropy source and
> (P)RNG lately.
>
> PHP already has a ini setting to define a strong entropy source for
> the session module, which defaults to urandom or arandom.
>
> I would like to create two settings to unify the entropy source
> accross php functions. That includes mcrypt, new password APIs,
> session, LCG, etc.
>
> Something along this line:
>
> random.entropy_strong_source (/dev/(u|a)random etc.)
> random.entropy_crypto_source (/dev/random etc.)
>
> I am not willing to propose new RNG functions or extensions for 5.6 as
> we have way too little time to actually discuss its design and APIs.
> However having these settings unified and documented would be a good
> step forward already.
>

To clarify what this proposal does (from otr discussion with Pierre):

 * openssl_pseudo_random_bytes - not changed
 * mcrypt_create_iv($n, MCRYPT_DEV_RANDOM) - uses crypto_source instead of
/dev/random
 * mcrypt_create_iv($n, MCRYPT_DEV_URANDOM) - uses strong_source instead of
/dev/urandom
 * mcrypt_create_iv($n, MCRYPT_RAND) - not changed
 * `password_hash()` - uses strong_source
 * session ID - uses strong_source
 * lcg_value, rand, mt_rand - not changed

Hope everything is correct :)

Nikita

---

## #72386 — padraic.brady@gmail.com — 2014-02-07T15:43:20+00:00

URL: https://externals.io/message/72374#72386 · In reply to: #72385

Hi Nikita,


> 
>
> > […]
>
> To clarify what this proposal does (from otr discussion with Pierre):
>
>  * openssl_pseudo_random_bytes - not changed
>  * mcrypt_create_iv($n, MCRYPT_DEV_RANDOM) - uses crypto_source instead of
> /dev/random
>  * mcrypt_create_iv($n, MCRYPT_DEV_URANDOM) - uses strong_source instead of
> /dev/urandom
>  * mcrypt_create_iv($n, MCRYPT_RAND) - not changed
>  * `password_hash()` - uses strong_source
>  * session ID - uses strong_source
>  * lcg_value, rand, mt_rand - not changed
>
> Hope everything is correct :)
>
> Nikita

Don't forget `array_rand()` and `shuffle()`... :P

But yes, that would be the expected outcome as I understand it.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

---

## #72395 — Yasuo Ohgaki — 2014-02-08T04:48:11+00:00

URL: https://externals.io/message/72374#72395 · In reply to: #72374

Hi Pierre,



> There are a lot of additions and discussions about entropy source and
> (P)RNG lately.
>
> PHP already has a ini setting to define a strong entropy source for
> the session module, which defaults to urandom or arandom.
>
> I would like to create two settings to unify the entropy source
> accross php functions. That includes mcrypt, new password APIs,
> session, LCG, etc.
>
> Something along this line:
>
> random.entropy_strong_source (/dev/(u|a)random etc.)
> random.entropy_crypto_source (/dev/random etc.)
>

+1 for unify.
BTW, it sound more natural if names are
random.entropy_crypto_source (/dev/(u|a)random etc.)
random.entropy_strong_source (/dev/random etc.)

I feels like 'strong' > 'crypto' with this naming.


>  I am not willing to propose new RNG functions or extensions for 5.6 as
> we have way too little time to actually discuss its design and APIs.
> However having these settings unified and documented would be a good
> step forward already.
>

Although, I really would like to have one, it's not much issue for me, but
a issue for average users ;)
This is possible implementation.

https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-random_bytes

It's not perfect yet, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72396 — Yasuo Ohgaki — 2014-02-08T04:50:49+00:00

URL: https://externals.io/message/72374#72396 · In reply to: #72377

Hi all,

On Fri, Feb 7, 2014 at 8:42 PM, Tjerk Meesters <tjerk.meesters@gmail.com>wrote:

> int random_integer($min, $max)
> string random_string($length, $crypto_safe)
>

I agree. This is better than

https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-random_bytes

as it can return unsafe mt_rand bytes. I'll improve it later.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72397 — Pierre Joye — 2014-02-08T07:13:35+00:00

URL: https://externals.io/message/72374#72397 · In reply to: #72395

>

>
> +1 for unify.
> BTW, it sound more natural if names are
> random.entropy_crypto_source (/dev/(u|a)random etc.)
> random.entropy_strong_source (/dev/random etc.)
>
> I feels like 'strong' > 'crypto' with this naming.

I did not invent this naming, it is used in many papers and docs to refer
to the quality of a PRNG.

> > […]
>
>
> Although, I really would like to have one, it's not much issue for me, but
> a issue for average users ;)
> This is possible implementation.
>
> https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-random_bytes
>
> It's not perfect yet, though.

There are many issues not being taken care here. Also a single function for
many different behaviors may not be what we wish.

I would suggest not to hurry up with it :)

Cheers,
Pierre

---

## #72547 — Yasuo Ohgaki — 2014-02-13T07:21:07+00:00

URL: https://externals.io/message/72374#72547 · In reply to: #72374

Hi all,



> There are a lot of additions and discussions about entropy source and
> (P)RNG lately.
>
> PHP already has a ini setting to define a strong entropy source for
> the session module, which defaults to urandom or arandom.
>
> I would like to create two settings to unify the entropy source
> accross php functions. That includes mcrypt, new password APIs,
> session, LCG, etc.
>
> Something along this line:
>
> random.entropy_strong_source (/dev/(u|a)random etc.)
> random.entropy_crypto_source (/dev/random etc.)
>
> I am not willing to propose new RNG functions or extensions for 5.6 as
> we have way too little time to actually discuss its design and APIs.
> However having these settings unified and documented would be a good
> step forward already.
>
> Thoughts?
>

I would like to have this.
This simplifies code uses /dev/*random.

I may write patch for this as well as
rand_strong_bytes()/rand_crypto_bytes().
Since it's too late for 5.6, I'll commit only to master.
Does anyone think this change needs RFC?

Or this is mandatory for good security, include it in 5.6?
What do you think, Julien?

Regards

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72549 — Pierre Joye — 2014-02-13T07:57:39+00:00

URL: https://externals.io/message/72374#72549 · In reply to: #72547

>
> Hi all,

> I may write patch for this as well as
rand_strong_bytes()/rand_crypto_bytes().

I would not go with these functions now, not even master only. Let first be
sure about what and how we want them.

> Since it's too late for 5.6, I'll commit only to master.
> Does anyone think this change needs RFC?

The entropy src needs one I think as it introduce two new ini settings.

Cheers,
Pierre

---

## #72551 — Yasuo Ohgaki — 2014-02-13T08:46:38+00:00

URL: https://externals.io/message/72374#72551 · In reply to: #72549

Hi Pierre,



> > […]
> rand_strong_bytes()/rand_crypto_bytes().
>
> I would not go with these functions now, not even master only. Let first
> be sure about what and how we want them.
>
No problem. I suppose you have an idea since you are working on new crypt
extension.

> > […]
>
> The entropy src needs one I think as it introduce two new ini settings.
>
Sure.
I don't mind creating new RFC for those 2 new INIs.
I'll create it later for master for the time being.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72552 — Yasuo Ohgaki — 2014-02-13T09:11:44+00:00

URL: https://externals.io/message/72374#72552 · In reply to: #72551

> > […]
> Sure.
> I don't mind creating new RFC for those 2 new INIs.
> I'll create it later for master for the time being.
>

https://wiki.php.net/rfc/unified-crypto-source

Done.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #72553 — Pierre Joye — 2014-02-13T09:36:27+00:00

URL: https://externals.io/message/72374#72553 · In reply to: #72552

Hi!


>
>
> 
> > […]
>
>
> https://wiki.php.net/rfc/unified-crypto-source
>
Thanks!

session.entropy_file won't be deprecated but will share the same, or can
share the same source. I can perfectly imagine large set oh hosts using two
sources, one for session and one for user land usages.

On windows they are not ignored but must be set. We can always add support
for hardware RNG or servers. A couple of good ones exist but we need to
test them (stream). We only support the windows crypto api for now.

There will be no hard coded default values but compile time default values
(as we do it now for other settings). These settings must system settings,
apps should not be able to change them.

The open issue can be dropped. We are not going to provide that through
these settings, not now.

Target is 5.6.

Cheers,
Pierre

---

## #72554 — Yasuo Ohgaki — 2014-02-13T10:42:01+00:00

URL: https://externals.io/message/72374#72554 · In reply to: #72553

Hi Pierre,



> session.entropy_file won't be deprecated but will share the same, or can
> share the same source. I can perfectly imagine large set oh hosts using two
> sources, one for session and one for user land usages.
>
> On windows they are not ignored but must be set. We can always add support
> for hardware RNG or servers. A couple of good ones exist but we need to
> test them (stream). We only support the windows crypto api for now.
>
> There will be no hard coded default values but compile time default values
> (as we do it now for other settings). These settings must system settings,
> apps should not be able to change them.
>
> The open issue can be dropped. We are not going to provide that through
> these settings, not now.
>
> Target is 5.6.
>
Updated the RFC to reflect your comment.
I might not understand default INI setting. I removed hard coded default
and made these INIs as `INI_PERDIR` and build time defined. i.e. Decided by
platform.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net