Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP
...
// changed functions (added optional $algo argument)
void srand($seed = null, $algo = rand_algo_default())
int rand($min = 0, $max = getrandmax(), $algo = rand_algo_default())
mixed array_rand(array $input, $num_req = 1, $algo = rand_algo_default())
bool shuffle(array &$array, $algo = rand_algo_default())
string str_shuffle(string $str, $algo = rand_algo_default())
// new functions
// set/get the default algo
int rand_algo_default($algo = null)
// get a list of available algos
array rand_algo_list()
// generate random $length bytes
string str_rand($length = 1, $algo = rand_algo_default())
// deprecate functions
mt_srand()
mt_rand()
mt_getrandmax()
openssl_random_pseudo_bytes()
gmp_random()
What do you think?
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP
(...)
What do you think?
Why do you want them?
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP(...)
What do you think?
Why do you want them?
This proposal is good because we need the best random function available in
a system
with easy to use API. I would like to see the best algorithm in a system as
default.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Am 30.08.2013 04:30, schrieb Yasuo Ohgaki:
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP(...)
What do you think?
Why do you want them?
This proposal is good because we need the best random function available in
a system
with easy to use API. I would like to see the best algorithm in a system as
default.
Defining the "best" algorithm as the standard default would be great but
what is the best algorithm? Some are fast but less secure and other are
more secure but slow.
Some times ago i read a feature request to implement the mersenne
twister algorithm for rand/shuffle/array_rand but this was closed
because it would be a bc break. (can't find it new).
Best Regards
Marc
what is the best algorithm?
Well that is platform dependant. For example on FreeBSD you'd hope
/dev/random was used (which does not block like linux, and generates a
crypto quality pseudo-random stream)
Point being, "best" is not easily defined by a constant.
Actually, a better approach is to use /dev/urandom to seed a PRG.
See my previous email in this thread regarding the FIPS approved generators.
Bryan
-----Original Message-----
From: Leigh [mailto:leight@gmail.com]
Sent: Friday, August 30, 2013 6:27 PM
To: Marc Bennewitz
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] More powerful (and backward compatible) API of random
number generator functions
what is the best algorithm?
Well that is platform dependant. For example on FreeBSD you'd hope
/dev/random was used (which does not block like linux, and generates a
crypto quality pseudo-random stream)
Point being, "best" is not easily defined by a constant.
First, I want to ask: Does anyone else think we should draw a distinction between RNGs and CSPRNGs?
I ask this because the OpenSSL option here is the only CSPRNG; The others are trivially breakable and should not be used for cryptographic applications. I could see an argument for wanting to use them in non-security contexts but I'm wondering if the API should make it clear when that is being done.
Secondly, a good place to look for defining a standard secure CSPRNG is FIPS 1402 Annex C (csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf)
Bryan
-----Original Message-----
From: Marc Bennewitz [mailto:php@marc-bennewitz.de]
Sent: Friday, August 30, 2013 2:59 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functions
Am 30.08.2013 04:30, schrieb Yasuo Ohgaki:
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP(...)
What do you think?
Why do you want them?
This proposal is good because we need the best random function
available in a system with easy to use API. I would like to see the
best algorithm in a system as default.
Defining the "best" algorithm as the standard default would be great but what is the best algorithm? Some are fast but less secure and other are more secure but slow.
Some times ago i read a feature request to implement the mersenne twister algorithm for rand/shuffle/array_rand but this was closed because it would be a bc break. (can't find it new).
Best Regards
Marc
Am 31.08.2013 03:17, schrieb Bryan C. Geraghty:
First, I want to ask: Does anyone else think we should draw a distinction between RNGs and CSPRNGs?
I ask this because the OpenSSL option here is the only CSPRNG; The others are trivially breakable and should not be used for cryptographic applications. I could see an argument for wanting to use them in non-security contexts but I'm wondering if the API should make it clear when that is being done.
Secondly, a good place to look for defining a standard secure CSPRNG is FIPS 1402 Annex C (csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf)
The listed constants are the one currently available in PHP. No more no
less.
I agree to have a CSPRNG defined as default but this should be the case
on all systems also without openssl dev/urandom ... (I don't know if
FIPS 1402 Annex C works on all systems).
For other modules like openssl/gmp it should be possible to add there
own algorithm that can be used with the same simple API.
Bryan
-----Original Message-----
From: Marc Bennewitz [mailto:php@marc-bennewitz.de]
Sent: Friday, August 30, 2013 2:59 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] More powerful (and backward compatible) API of random number generator functionsAm 30.08.2013 04:30, schrieb Yasuo Ohgaki:
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP(...)
What do you think?
Why do you want them?
This proposal is good because we need the best random function
available in a system with easy to use API. I would like to see the
best algorithm in a system as default.Defining the "best" algorithm as the standard default would be great but what is the best algorithm? Some are fast but less secure and other are more secure but slow.
Some times ago i read a feature request to implement the mersenne twister algorithm for rand/shuffle/array_rand but this was closed because it would be a bc break. (can't find it new).
Best Regards
Marc
Hi,
I ask this because the OpenSSL option here is the only CSPRNG; The others
are trivially breakable and should not be used for cryptographic
applications. I could see an argument for wanting to use them in
non-security contexts but I'm wondering if the API should make it clear
when that is being done.
if you mean openssl_random_pseudo_bytes, then it's not CSPRNG because it
calls RAND_pseudo_bytes. You would have to use RAND_bytes to have CSPRNG
but then you would have to seeded before calling. See
http://www.openssl.org/docs/crypto/RAND_bytes.html and OpenSSL sources for
more details.
I don't think that using OpenSSL here is a good idea. There should be a
better framework or new functions for dealing with OpenSSL Rand but that's
a bit off topic...
The whole proposal is a bit confusing for me. The combination of PRNG
algorithm (MT) with libraries (libc, OpenSSL, GMP) that implements one or
more PRNG algorithms just doesn't make sense to me. It doesn't say anything
about the speed and crypto strength of the algorithms. I think that much
better solution would be an extension that implements a couple of
algorithms. Then you could select what algorithm you want to use. The good
idea would be to have some reasonable default algorithm that would be used
if the user doesn't know anything about algorithms. This could be
implemented as an extension and if it's good enough then it could be
proposed as the core addition.
Jakub
Am 01.09.2013 15:12, schrieb Jakub Zelenka:
The whole proposal is a bit confusing for me. The combination of PRNG
algorithm (MT) with libraries (libc, OpenSSL, GMP) that implements one or
more PRNG algorithms just doesn't make sense to me. It doesn't say anything
about the speed and crypto strength of the algorithms. I think that much
better solution would be an extension that implements a couple of
algorithms. Then you could select what algorithm you want to use. The good
idea would be to have some reasonable default algorithm that would be used
if the user doesn't know anything about algorithms. This could be
implemented as an extension and if it's good enough then it could be
proposed as the core addition.
Agree, libc, openssl etc. are not algorithms and the name should reflect
the used algorithm not the name of the library.
Implementing it as an extension is ok - but the proposal also was to
have more possibilities without bc using the default build-in functions.
Additionally it would be great to have one standard API other extension
can attach it's own algorithm to.
Marc
The whole proposal is a bit confusing for me. The combination of PRNG
algorithm (MT) with libraries (libc, OpenSSL, GMP) that implements one or
more PRNG algorithms just doesn't make sense to me. It doesn't say anything
about the speed and crypto strength of the algorithms. I think that much
better solution would be an extension that implements a couple of
algorithms. Then you could select what algorithm you want to use. The good
idea would be to have some reasonable default algorithm that would be used
if the user doesn't know anything about algorithms. This could be
implemented as an extension and if it's good enough then it could be
proposed as the core addition.
Except a few very well known algorithm (MT, SIMD MT and the likes)
with well tested implementation, I would not even try to implement
anything else on our own, even less for crypto safe algorithms. This
is something really hard to implement and I know very little new
algorithm or new implementations actually working as expected, and
they were done by experts, not people like you and me :)
Relying on well tested libraries or devices (harware like those
avaiable in the new haswel serie, /dev/*random, etc.) is a much
better approach and let us focus on the APIs we will provide in the
userland side.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org