Edit report at http://bugs.php.net/bug.php?id=52523&edit=1

 ID:                 52523
 Updated by:         der...@php.net
 Reported by:        php-bugs at thequod dot de
 Summary:            mcrypt_create_iv not reliable on win: "Could not
                     gather sufficient random data"
 Status:             Assigned
 Type:               Feature/Change Request
 Package:            mcrypt related
 Operating System:   *
 PHP Version:        5.3.3
 Assigned To:        pajoye
 Block user comment: N

 New Comment:

This is a bug actually. /dev/random is supposed to wait as long as there
is enough entropy. /dev/urandom cares less (and is a worse source of
entropy). The behaviour on Windows needs to behave the same as on a
Unix.


Previous Comments:
------------------------------------------------------------------------
[2010-08-03 17:07:27] php-bugs at thequod dot de

Windows:

% while php -r '$s = microtime(true); if( mcrypt_create_iv(16,
MCRYPT_DEV_RANDOM) === false ) exit(1); $e = microtime(true);
printf("%.5f\n", $e-$s);'; do true; done

0.00449

0.00454



Fatal error: mcrypt_create_iv(): Could not gather sufficient random data
in Command line code on line 1





Linux:

# while php -r '$s = microtime(true); if( mcrypt_create_iv(16,
MCRYPT_DEV_RANDOM) === false ) exit(1); $e = microtime(true);
printf("%.2f\n", $e-$s);'; do true; done

0.00

3.51

3.56

4.03

3.58

4.06

3.71

5.12

4.19

3.41

3.87

3.91

3.74

5.09

4.26

3.71

3.78

4.41

5.48

5.09

6.50

4.14

3.58

3.83

6.02

3.74

3.87

4.68

6.92

4.52

6.01

...



Completely different machines though, of course.

------------------------------------------------------------------------
[2010-08-03 16:59:06] php-bugs at thequod dot de

JFI: it gets used in Typo3 to get random data (via
generateRandomBytes).



Added in

http://github.com/typo3/typo3v4core/commit/00ce0fe45aa46b62e8aa499912c9e36483185737



Also, it appears to be blocking (at least for longer) on Linux; it takes
up to a few seconds for each call, but appears to fail instantly on
Windows.

(not sure though)

------------------------------------------------------------------------
[2010-08-03 16:16:18] paj...@php.net

Yes, it can but very unlikely. The only case where it fails on the 1st
iteration is when I do such loops in parallel.



Hard to fix and not sure it is worth the effort. One argued once about
hi traffic site, but in this exact case the system activity provides
enough rng data (not like your example).



Changing to feature request and we will see what can be done (as it is
not windows specific, the timeout request).

------------------------------------------------------------------------
[2010-08-03 16:05:11] php-bugs at thequod dot de

Yes, I expect it to be blocking, at least for a certain amount of time
(why not for the maximum execution time?).



While the endless loop is unrealistic of course, it's only meant for
demonstration; it may fail with the first call already, according to the
following (cygwin code):

  while php -r "if( mcrypt_create_iv(16, MCRYPT_DEV_RANDOM) === false )
exit(1);"; do ; done

------------------------------------------------------------------------
[2010-08-03 15:55:44] paj...@php.net

It is reliable as it fits in the mcrypt main goal, crypto safe output.



However, do you expect it to be blocking like /dev/random? By blocking
that means it won't return until it gets the requested amount of random
data.



I'd to say that this example is not realistic at all, or nobody should
do that in a real world application. It is important to keep in mind
that an app will do it once per request for example, allowing the system
seed the random sources again between calls. That's almost not possible
in your example and that defeats the whole idea behind such functions.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=52523


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52523&edit=1

Reply via email to