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
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
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
Hi all,
On Fri, Feb 7, 2014 at 8:42 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
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
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
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 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 havemt_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
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
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
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.
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).
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
Hi Nikita,
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
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
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
+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.
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.
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
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
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
Hi Pierre,
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.
No problem. I suppose you have an idea since you are working on new crypt
extension.
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.
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
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.
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
Hi!
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.
Sure.
I don't mind creating new RFC for those 2 new INIs.
I'll create it later for master for the time being.
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
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