Hello internals,
there has already been a lot of talk about improving secure random number generation for PHP6. One thing I'd like to improve as well, would be non-secure random number generation. Here is not so much security at stake but ease of use.
The obvious solution, would be to rename mt_rand to rand and make rand an alias. (The same for the supporting functions mt_srand and mt_getrandmax).
What I'm missing is the history. What was the reason to keep the separate? Am I missing something?
Best regards
Rouven
On Sun, Feb 23, 2014 at 7:45 PM, Rouven Weßling me@rouvenwessling.dewrote:
Hello internals,
there has already been a lot of talk about improving secure random number
generation for PHP6. One thing I'd like to improve as well, would be
non-secure random number generation. Here is not so much security at stake
but ease of use.The obvious solution, would be to rename mt_rand to rand and make rand an
alias. (The same for the supporting functions mt_srand and mt_getrandmax).What I'm missing is the history. What was the reason to keep the separate?
Am I missing something?Best regards
Rouven
Changing the random number generation algorithm is a BC break, e.g. tests
could rely on certain random number sequences for a certain seed. However
it sounds reasonable to make rand, array_shuffle, str_shuffle etc make use
of MT 19937 in PHP6, as we have a bit more freedom with breakage.
Nikita
Hi!
Changing the random number generation algorithm is a BC break, e.g. tests
could rely on certain random number sequences for a certain seed. However
I would say anybody who relies on RNG producing preset numbers is asking
for trouble. If you need mock RNG, mock it out, don't rely on
undocumented properties of the system one.
But then again, refactoring and unifying RNGs is not very urgent thing
and a good candidate to put in a major version.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I would say anybody who relies on RNG producing preset numbers is asking
for trouble. If you need mock RNG, mock it out, don't rely on
undocumented properties of the system one.
But then again, refactoring and unifying RNGs is not very urgent thing
and a good candidate to put in a major version.
What? PRNGs guarantee that for a given seed they will always produce the same sequence. All sorts of things do and should rely on this.
--
Andrea Faulds
http://ajf.me/
I would say anybody who relies on RNG producing preset numbers is asking
for trouble. If you need mock RNG, mock it out, don't rely on
undocumented properties of the system one.
But then again, refactoring and unifying RNGs is not very urgent thing
and a good candidate to put in a major version.What? PRNGs guarantee that for a given seed they will always produce the same sequence. All sorts of things do and should rely on this.
Yup, there is a lot of code out there that relies on this. Plenty of games rely on this for replays or world generation. Just look at Minecraft world seeds, for example.
-Rasmus
I would say anybody who relies on RNG producing preset numbers is asking
for trouble. If you need mock RNG, mock it out, don't rely on
undocumented properties of the system one.
But then again, refactoring and unifying RNGs is not very urgent thing
and a good candidate to put in a major version.What? PRNGs guarantee that for a given seed they will always produce the same sequence. All sorts of things do and should rely on this.
As far as rand() is concerned, this already doesn't work. As it's using the system rand it might change behavior when changing to a different OS for example. In this regards the change actually helps.
That said, I think it's a very bad idea to use a non-random seed with mt_srand() or srand() as a lot of code fall backs to them when no secure alternative exists. Also some library may use them to decide things that should actually be random. Maybe it would be a good idea to deprecate those and not include them in PHP6? It's probably safer to provide a dedicated sequence generator, than having people abuse our PRNGs.
Maybe it would be a good idea to deprecate those and not include them in PHP6? It's probably safer to provide a dedicated sequence generator, than having people abuse our PRNGs.
Coming back to this, I hacked up a sequence generator we could include PHP 5.x to reduce these concerns: https://github.com/realityking/php-src/compare/php:master...realityking:sequenceGenerator
If there's interest in this, I'd clean it up (lots of duplicated code between mt_rand and this right now) and propose it for 5.7.
Best regards
Rouven
Hi Rowen,
Hello internals,
there has already been a lot of talk about improving secure random number generation for PHP6. One thing I'd like to improve as well, would be non-secure random number generation. Here is not so much security at stake but ease of use.
The obvious solution, would be to rename mt_rand to rand and make rand an alias. (The same for the supporting functions mt_srand and mt_getrandmax).
What I'm missing is the history. What was the reason to keep the separate? Am I missing something?
I totally agree with your goals. There are too many ways to do the
same operations, in many areas. However I am not a fan of breaking BC
(even in small ways) without an actual big benefit. It is always easy
to remove, kill, change functions to make them "better". Adding each
single change together will make a migration to a given version almost
impossible or very painful. I would go with a soft way.
In the case of the random functions, as I said in previous
discussions, I tend to go with a new APIs, clean, with a couple more
algorithms as well as easy to use functions for the common usages
(crypto safe or not). Anthony implemented something in userland, there
are a couple of libraries available too (in C, used by python f.e.)
providing very handy APIs. That's the way I would choose.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi,
Hi Rowen,
Hello internals,
there has already been a lot of talk about improving secure random number generation for PHP6. One thing I'd like to improve as well, would be non-secure random number generation. Here is not so much security at stake but ease of use.
The obvious solution, would be to rename mt_rand to rand and make rand an alias. (The same for the supporting functions mt_srand and mt_getrandmax).
What I'm missing is the history. What was the reason to keep the separate? Am I missing something?
Well, they do two different things so keeping them separate seems like
a good idea ;).
I totally agree with your goals. There are too many ways to do the
same operations, in many areas. However I am not a fan of breaking BC
(even in small ways) without an actual big benefit. It is always easy
to remove, kill, change functions to make them "better". Adding each
single change together will make a migration to a given version almost
impossible or very painful. I would go with a soft way.In the case of the random functions, as I said in previous
discussions, I tend to go with a new APIs, clean, with a couple more
algorithms as well as easy to use functions for the common usages
(crypto safe or not). Anthony implemented something in userland, there
are a couple of libraries available too (in C, used by python f.e.)
providing very handy APIs. That's the way I would choose.
New APIs would be preferable. Technically, there's nothing wrong with
mt_rand() since it does what it says on the box. A mt_rand() function
that isn't predictable using a known seed is actually broken ;).
Leaking its values may have implications since the seed is vulnerable
to recovery, but it already has a bad rep for use anywhere in
security.
Anthony's library is quite good for cases where getting a decent
crypto safe random value isn't possible, but it's really something of
a last resort and the thing that makes it decent is the algorithm for
mixing entropy sources.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
L
Anthony's library is quite good for cases where getting a decent
crypto safe random value isn't possible, but it's really something of
a last resort and the thing that makes it decent is the algorithm for
mixing entropy sources.
I was referring to the APIs not the implementation :)