Uuid:uuid4() collisions #80

Closed
giorgiosironi opened this Issue Aug 27, 2015 · 87 comments

Comments

@giorgiosironi

We are generating about 1M UUID4 a day, and we are getting several hundred collisions a day, such as:

[2015-08-26 21:29:19 +0200] [production-onebipws-1.apache - 17819] [DEBUG] [Request] 
time_total=0.145
"request_id":"fdfb98c1-4367-4f22-b68a-d7cdaedcc069" 

[2015-08-27 00:36:16 +0200] [production-onebipws-1.apache - 17819] [DEBUG] [Request] 
time_total=0.016
"request_id":"fdfb98c1-4367-4f22-b68a-d7cdaedcc069"

The issue seem to be correlated with the same Apache process regenerating the same UUID after several hours. It also seem to be correlated with particular EC2 machines which presents the problem.

We checked to have openssl_random_pseudo_bytes and if it was using a strong algorithm:

root@dev-all-onebip:~/projects/.../onebip-ultimate$  (master) # php -r "var_dump(function_exists('openssl_random_pseudo_bytes'));"                                      
bool(true)
root@dev-all-onebip:~/projects/.../onebip-ultimate$  (master) # php -r 'openssl_random_pseudo_bytes(16, $strong); var_dump($strong);'
bool(true)

How can we debug this problem?

@ircmaxell

This comment has been minimized.

Show comment
Hide comment
@ircmaxell

ircmaxell Aug 27, 2015

Which version of UUID are you using? Can you try switching to master?

Which version of UUID are you using? Can you try switching to master?

@giorgiosironi

This comment has been minimized.

Show comment
Hide comment
@giorgiosironi

giorgiosironi Aug 27, 2015

We are on 2.8.1, but from what I see the code for uuid4() is identical to master:

public static function uuid4()
{
    $bytes = self::generateBytes(16);
    // When converting the bytes to hex, it turns into a 32-character
    // hexadecimal string that looks a lot like an MD5 hash, so at this
    // point, we can just pass it to uuidFromHashedName. 
    $hex = bin2hex($bytes);
    return self::uuidFromHashedName($hex, 4);
}

private static function generateBytes($length)
{
    if (self::hasOpensslRandomPseudoBytes()) {
        return openssl_random_pseudo_bytes($length);
    }
    ...
}

Here is a sample of the duplicated UUIDs:
https://gist.github.com/giorgiosironi/f1ce4682868ca6a6279d

We are on 2.8.1, but from what I see the code for uuid4() is identical to master:

public static function uuid4()
{
    $bytes = self::generateBytes(16);
    // When converting the bytes to hex, it turns into a 32-character
    // hexadecimal string that looks a lot like an MD5 hash, so at this
    // point, we can just pass it to uuidFromHashedName. 
    $hex = bin2hex($bytes);
    return self::uuidFromHashedName($hex, 4);
}

private static function generateBytes($length)
{
    if (self::hasOpensslRandomPseudoBytes()) {
        return openssl_random_pseudo_bytes($length);
    }
    ...
}

Here is a sample of the duplicated UUIDs:
https://gist.github.com/giorgiosironi/f1ce4682868ca6a6279d

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Aug 27, 2015

Owner

I wonder if you'll experience the same if you switch to using @ircmaxell's RandomLib.

Using master or 3.0.0-alpha3, you can do so like this:

$uuidFactory = new \Ramsey\Uuid\UuidFactory();
$uuidFactory->setRandomGenerator(new \Ramsey\Uuid\Generator\RandomLibAdapter());
\Ramsey\Uuid\Uuid::setFactory($uuidFactory);

$uuid = \Ramsey\Uuid\Uuid::uuid4();
Owner

ramsey commented Aug 27, 2015

I wonder if you'll experience the same if you switch to using @ircmaxell's RandomLib.

Using master or 3.0.0-alpha3, you can do so like this:

$uuidFactory = new \Ramsey\Uuid\UuidFactory();
$uuidFactory->setRandomGenerator(new \Ramsey\Uuid\Generator\RandomLibAdapter());
\Ramsey\Uuid\Uuid::setFactory($uuidFactory);

$uuid = \Ramsey\Uuid\Uuid::uuid4();
@giorgiosironi

This comment has been minimized.

Show comment
Hide comment
@giorgiosironi

giorgiosironi Aug 27, 2015

Currently I am trying to reproduce the problem with a cli script to avoid impacting the production system, if I have a test that produces collisions I will try rerun it with RandomLib.

Currently I am trying to reproduce the problem with a cli script to avoid impacting the production system, if I have a test that produces collisions I will try rerun it with RandomLib.

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Aug 27, 2015

Owner

Can you share your test that produces collisions? Does it consistently reproduce them, and is it always reproducing them for the same UUIDs?

Owner

ramsey commented Aug 27, 2015

Can you share your test that produces collisions? Does it consistently reproduce them, and is it always reproducing them for the same UUIDs?

@fabre-thibaud

This comment has been minimized.

Show comment
Hide comment
@fabre-thibaud

fabre-thibaud Aug 27, 2015

Contributor

Yup, would be interesting to have more information on your setup (OS version, openssl version, machine architecture (x86 vs x86_64) ... the more the better)

I'm unable to get a single collision on a 12M set:

<?php

require_once 'vendor/autoload.php';

while (1) {
    file_put_contents('uuids.txt', \Rhumsaa\Uuid\Uuid::uuid4() . PHP_EOL, FILE_APPEND);
}
thibaud@thibaud-zbox:~/Workspaces/uuid$ wc -l uuids.txt 
12143446 uuids.txt
thibaud@thibaud-zbox:~/Workspaces/uuid$ sort uuids.txt | uniq -d
thibaud@thibaud-zbox:~/Workspaces/uuid$

EDIT This is with OpenSSL enabled

Contributor

fabre-thibaud commented Aug 27, 2015

Yup, would be interesting to have more information on your setup (OS version, openssl version, machine architecture (x86 vs x86_64) ... the more the better)

I'm unable to get a single collision on a 12M set:

<?php

require_once 'vendor/autoload.php';

while (1) {
    file_put_contents('uuids.txt', \Rhumsaa\Uuid\Uuid::uuid4() . PHP_EOL, FILE_APPEND);
}
thibaud@thibaud-zbox:~/Workspaces/uuid$ wc -l uuids.txt 
12143446 uuids.txt
thibaud@thibaud-zbox:~/Workspaces/uuid$ sort uuids.txt | uniq -d
thibaud@thibaud-zbox:~/Workspaces/uuid$

EDIT This is with OpenSSL enabled

@ircmaxell

This comment has been minimized.

Show comment
Hide comment
@ircmaxell

ircmaxell Aug 27, 2015

Try generating them on multiple servers. Part of mt_rand()'s output is based on server timestamp, so collisions are probable there (assuming openssl disabled).

Try generating them on multiple servers. Part of mt_rand()'s output is based on server timestamp, so collisions are probable there (assuming openssl disabled).

@giorgiosironi

This comment has been minimized.

Show comment
Hide comment
@giorgiosironi

giorgiosironi Aug 27, 2015

I do not have yet a script reproducing the problem (it's production traffic presenting the issue), but it happens on a single server, also as stated in the first comment we have the openssl extension enabled.
Versions:

root@production-onebipws-1:~$  # openssl version
OpenSSL 1.0.1 14 Mar 2012
root@production-onebipws-1:~$  # php -v
PHP 5.4.43-1+deb.sury.org~precise+1 (cli) (built: Jul 15 2015 12:05:17) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies

I do not have yet a script reproducing the problem (it's production traffic presenting the issue), but it happens on a single server, also as stated in the first comment we have the openssl extension enabled.
Versions:

root@production-onebipws-1:~$  # openssl version
OpenSSL 1.0.1 14 Mar 2012
root@production-onebipws-1:~$  # php -v
PHP 5.4.43-1+deb.sury.org~precise+1 (cli) (built: Jul 15 2015 12:05:17) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies
@ircmaxell

This comment has been minimized.

Show comment
Hide comment
@ircmaxell

ircmaxell Aug 27, 2015

That's a very serious problem then. Could you check to see if the $strong parameter of openssl_random_pseudo_bytes() is showing true or false on this server?

That's a very serious problem then. Could you check to see if the $strong parameter of openssl_random_pseudo_bytes() is showing true or false on this server?

@fabre-thibaud

This comment has been minimized.

Show comment
Hide comment
@fabre-thibaud

fabre-thibaud Aug 27, 2015

Contributor

@ircmaxell He mentionned in the first post that it returns true :)

@giorgiosironi Does it happen on any other server or only that one ? Is there a software (OS, PHP, OpenSSL) version difference between that specific server and the others that do not collide ?

Contributor

fabre-thibaud commented Aug 27, 2015

@ircmaxell He mentionned in the first post that it returns true :)

@giorgiosironi Does it happen on any other server or only that one ? Is there a software (OS, PHP, OpenSSL) version difference between that specific server and the others that do not collide ?

@ircmaxell

This comment has been minimized.

Show comment
Hide comment
@ircmaxell

ircmaxell Aug 27, 2015

He may be getting true from the command line. That doesn't mean it can't
return different values during load, or when these collisions are
generated...
On Aug 27, 2015 12:10 PM, "Thibaud Fabre" notifications@github.com wrote:

@ircmaxell https://github.com/ircmaxell He mentionned in the first post
that it returns true :)

@giorgiosironi https://github.com/giorgiosironi Does it happen on any
other server or only that one ? Is there a software (OS, PHP, OpenSSL)
version difference between that specific server and the others that do not
collide ?


Reply to this email directly or view it on GitHub
#80 (comment).

He may be getting true from the command line. That doesn't mean it can't
return different values during load, or when these collisions are
generated...
On Aug 27, 2015 12:10 PM, "Thibaud Fabre" notifications@github.com wrote:

@ircmaxell https://github.com/ircmaxell He mentionned in the first post
that it returns true :)

@giorgiosironi https://github.com/giorgiosironi Does it happen on any
other server or only that one ? Is there a software (OS, PHP, OpenSSL)
version difference between that specific server and the others that do not
collide ?


Reply to this email directly or view it on GitHub
#80 (comment).

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Sep 2, 2015

Owner

Any more word on this? @renan reported similar findings on Twitter:

https://twitter.com/renan_saddam/status/637024558038544388

Owner

ramsey commented Sep 2, 2015

Any more word on this? @renan reported similar findings on Twitter:

https://twitter.com/renan_saddam/status/637024558038544388

@kbond kbond referenced this issue in ircmaxell/RandomLib Sep 4, 2015

Closed

7 character base62 collision #38

@giorgiosironi

This comment has been minimized.

Show comment
Hide comment
@giorgiosironi

giorgiosironi Sep 6, 2015

What we have done until now:

  • implemented retry on collisions with a new generation to avoid data loss
  • extracting data lost in the last two months
  • reimporting it in the system
  • switched back the code to the uniqid()+mt_rand() previous implementation, which has still caused collisions in the past but at a 1% rate with respect to openssl

What we have done until now:

  • implemented retry on collisions with a new generation to avoid data loss
  • extracting data lost in the last two months
  • reimporting it in the system
  • switched back the code to the uniqid()+mt_rand() previous implementation, which has still caused collisions in the past but at a 1% rate with respect to openssl
@fabre-thibaud

This comment has been minimized.

Show comment
Hide comment
@fabre-thibaud

fabre-thibaud Sep 6, 2015

Contributor

@giorgiosironi Did you manage to find out if openssl_random_pseudo_bytes was storing a false flag in the $strong argument when you get collisions ?

Contributor

fabre-thibaud commented Sep 6, 2015

@giorgiosironi Did you manage to find out if openssl_random_pseudo_bytes was storing a false flag in the $strong argument when you get collisions ?

@giorgiosironi

This comment has been minimized.

Show comment
Hide comment
@giorgiosironi

giorgiosironi Sep 6, 2015

No, because that would require forking the library and/or patching it in production which has an high development cost

No, because that would require forking the library and/or patching it in production which has an high development cost

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Sep 6, 2015

Owner

Can you put a single PHP script on one of the production machines and run it to see?

Owner

ramsey commented Sep 6, 2015

Can you put a single PHP script on one of the production machines and run it to see?

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Sep 6, 2015

Owner

Or maybe I misunderstood the ask. I see @aztech-dev was asking if you could see if $strong is false only when you see a collision. Sorry for the confusion.

Owner

ramsey commented Sep 6, 2015

Or maybe I misunderstood the ask. I see @aztech-dev was asking if you could see if $strong is false only when you see a collision. Sorry for the confusion.

@giorgiosironi

This comment has been minimized.

Show comment
Hide comment
@giorgiosironi

giorgiosironi Sep 6, 2015

About the single PHP script, I did run the same code shown in #80 (comment) in the affected servers and it gave the same result of the function being present and $strong being true.

About the single PHP script, I did run the same code shown in #80 (comment) in the affected servers and it gave the same result of the function being present and $strong being true.

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Sep 6, 2015

Owner

@giorgiosironi I see your PHP and OpenSSL versions above. What EC2 instance type are you using, since you mentioned that you see this happening on a specific EC2 instance type?

Owner

ramsey commented Sep 6, 2015

@giorgiosironi I see your PHP and OpenSSL versions above. What EC2 instance type are you using, since you mentioned that you see this happening on a specific EC2 instance type?

@renan

This comment has been minimized.

Show comment
Hide comment
@renan

renan Sep 7, 2015

I am logging the collisions to see how frequent they are, if any.

In the meantime I have executed the test script @aztech-dev provided in few machines:

  • No collisions on a 2.5M set when running on MacBook Pro with latest OS X, PHP 5.5.26, and OpenSSL 0.9.8zg
  • No collisions on a 23.7M set on Ubuntu 14.04.3 running PHP 5.5.9, and OpenSSL 1.0.1f

The server of which gave me collisions is not around anymore, but was running Ubuntu 12.04.4, PHP 5.3.x and don't know the OpenSSL version. But was all from Ubuntu LTS versions.

renan commented Sep 7, 2015

I am logging the collisions to see how frequent they are, if any.

In the meantime I have executed the test script @aztech-dev provided in few machines:

  • No collisions on a 2.5M set when running on MacBook Pro with latest OS X, PHP 5.5.26, and OpenSSL 0.9.8zg
  • No collisions on a 23.7M set on Ubuntu 14.04.3 running PHP 5.5.9, and OpenSSL 1.0.1f

The server of which gave me collisions is not around anymore, but was running Ubuntu 12.04.4, PHP 5.3.x and don't know the OpenSSL version. But was all from Ubuntu LTS versions.

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Sep 7, 2015

Owner

I don't have any data to base this on, but off the cuff, it sounds like the underlying system has a lack of randomness on it. Maybe?

Owner

ramsey commented Sep 7, 2015

I don't have any data to base this on, but off the cuff, it sounds like the underlying system has a lack of randomness on it. Maybe?

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Sep 30, 2015

Owner

Just a thought: can you set up monitoring such that, when a collision occurs, you get a report on the read-out of the current value in /proc/sys/kernel/random/entropy_avail?

If the number is > 200, then your entropy level is good. If it's < 200, then that's an indication that there's a problem.

Owner

ramsey commented Sep 30, 2015

Just a thought: can you set up monitoring such that, when a collision occurs, you get a report on the read-out of the current value in /proc/sys/kernel/random/entropy_avail?

If the number is > 200, then your entropy level is good. If it's < 200, then that's an indication that there's a problem.

@langemeijer

This comment has been minimized.

Show comment
Hide comment
@langemeijer

langemeijer Sep 30, 2015

I've been watching this thread, because it scared the shit out of me, but I want to share some of my initial thoughts here.

@giorgiosironi shared this piece of code:

private static function generateBytes($length)
{
    if (self::hasOpensslRandomPseudoBytes()) {
        return openssl_random_pseudo_bytes($length);
    }
    ...
}

For me the scary part is the dots. What's there? mt_rand to generate uuids?

In the first post in this issue he shared a piece of shell output

root@dev-all-onebip:~/projects/.../onebip-ultimate$  (master) # php -r "var_dump(function_exists('openssl_random_pseudo_bytes'));"                                      
bool(true)
root@dev-all-onebip:~/projects/.../onebip-ultimate$  (master) # php -r 'openssl_random_pseudo_bytes(16, $strong); var_dump($strong);'
bool(true)

But this doesn't prove that openssl is actually used in the generateBytes() method. I would have liked to see a phpinfo() output from a web request where we can confim that the openssl extension was actually loaded in the webserver.

Modern distro's have split the php.ini and conf.d for the cli and different sapi's. My guess is that openssl was loaded in cli, but not in webserver sapi.

I've been watching this thread, because it scared the shit out of me, but I want to share some of my initial thoughts here.

@giorgiosironi shared this piece of code:

private static function generateBytes($length)
{
    if (self::hasOpensslRandomPseudoBytes()) {
        return openssl_random_pseudo_bytes($length);
    }
    ...
}

For me the scary part is the dots. What's there? mt_rand to generate uuids?

In the first post in this issue he shared a piece of shell output

root@dev-all-onebip:~/projects/.../onebip-ultimate$  (master) # php -r "var_dump(function_exists('openssl_random_pseudo_bytes'));"                                      
bool(true)
root@dev-all-onebip:~/projects/.../onebip-ultimate$  (master) # php -r 'openssl_random_pseudo_bytes(16, $strong); var_dump($strong);'
bool(true)

But this doesn't prove that openssl is actually used in the generateBytes() method. I would have liked to see a phpinfo() output from a web request where we can confim that the openssl extension was actually loaded in the webserver.

Modern distro's have split the php.ini and conf.d for the cli and different sapi's. My guess is that openssl was loaded in cli, but not in webserver sapi.

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Sep 30, 2015

Owner

@langemeijer Here's that equivalent block of code in 3.0.0: https://github.com/ramsey/uuid/blob/3.0.0/src/Generator/RandomGeneratorFactory.php#L58-L74

Your comment makes me think it might be a good idea to "tag" a Uuid object at its point of creation with details about what generator, provider, etc. was used to create it. I'm not sure what this would look like in practice, and you may certainly create a Uuid from a string, bytes, or fields you pass in to it, so that information won't be available in that context, but it might be good to provide this information (when creating a Uuid) for debugging purposes.

Owner

ramsey commented Sep 30, 2015

@langemeijer Here's that equivalent block of code in 3.0.0: https://github.com/ramsey/uuid/blob/3.0.0/src/Generator/RandomGeneratorFactory.php#L58-L74

Your comment makes me think it might be a good idea to "tag" a Uuid object at its point of creation with details about what generator, provider, etc. was used to create it. I'm not sure what this would look like in practice, and you may certainly create a Uuid from a string, bytes, or fields you pass in to it, so that information won't be available in that context, but it might be good to provide this information (when creating a Uuid) for debugging purposes.

@matteosister

This comment has been minimized.

Show comment
Hide comment
@matteosister

matteosister Oct 6, 2015

I confirm that we also have collissions on our uuids.
We have a table with 2,5M rows. I grouped by unique identifier, and counted the occurrence, and I have many collisions. In one case I have 5 equal uuids.... 😨

We are on ec2 too.

I confirm that we also have collissions on our uuids.
We have a table with 2,5M rows. I grouped by unique identifier, and counted the occurrence, and I have many collisions. In one case I have 5 equal uuids.... 😨

We are on ec2 too.

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Oct 8, 2015

Owner

@matteosister Are you able to set up your environment so that you can capture information at the point a collision occurs? Specifically, what is the value of /proc/sys/kernel/random/entropy_avail when the collision occurs? Also, can you give specifics about the EC2 instance you're using (AWS instance type, uname -a, php --version, cat /etc/issue, etc.)?

Owner

ramsey commented Oct 8, 2015

@matteosister Are you able to set up your environment so that you can capture information at the point a collision occurs? Specifically, what is the value of /proc/sys/kernel/random/entropy_avail when the collision occurs? Also, can you give specifics about the EC2 instance you're using (AWS instance type, uname -a, php --version, cat /etc/issue, etc.)?

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Oct 8, 2015

Owner

@matteosister Also, an example of the code you're using to generate the UUIDs, too, please.

Owner

ramsey commented Oct 8, 2015

@matteosister Also, an example of the code you're using to generate the UUIDs, too, please.

@matteosister

This comment has been minimized.

Show comment
Hide comment
@matteosister

matteosister Oct 9, 2015

@ramsey we are trying to isolate the problem....and we have a suspect that something could be related to an edge case in our own code. I will report back when I'm sure. Thanks!

@ramsey we are trying to isolate the problem....and we have a suspect that something could be related to an edge case in our own code. I will report back when I'm sure. Thanks!

@Lansoweb

This comment has been minimized.

Show comment
Hide comment
@Lansoweb

Lansoweb Nov 15, 2015

@ramsey I'm running a test on 3 AWS instances (micro, small and medium), one CentOS and 2 AmazonLinux). Each one already has more than 2M (the micro has 12.134.008) without duplicates. Will keep running for a while and report back later. I'm also saving the entropy_avail with each uuid, to if i got a hit, will report the entropy as well.

@ramsey I'm running a test on 3 AWS instances (micro, small and medium), one CentOS and 2 AmazonLinux). Each one already has more than 2M (the micro has 12.134.008) without duplicates. Will keep running for a while and report back later. I'm also saving the entropy_avail with each uuid, to if i got a hit, will report the entropy as well.

@Lansoweb

This comment has been minimized.

Show comment
Hide comment
@Lansoweb

Lansoweb Nov 15, 2015

@ramsey Results:

  • Micro Instance AmazonLinux (almost 70M)
$ sort uuids.txt | uniq -d
$ wc -l uuids.txt
69589819 uuids.txt

Entropies around 3000

  • Small Instance AmazonLinux (10M)
$ sort uuids.txt | uniq -d
$ wc -l uuids.txt
10063312 uuids.txt

Entropies around 3000

  • Medium Instance CentOS (10M)
# sort uuids.txt | uniq -d
# wc -l uuids.txt
10181234 uuids.txt

Entropies around 200 (too low, maybe because kernel 2.6?), but still no dups.

No duplicates on any of them. Using the following php:

<?php
require_once 'vendor/autoload.php';
while (1) {
    $uuid = \Ramsey\Uuid\Uuid::uuid4();
    $entropy = trim(file_get_contents('/proc/sys/kernel/random/entropy_avail'));

    file_put_contents('uuids.txt', $uuid . PHP_EOL, FILE_APPEND);
    file_put_contents('uuids-entropies.txt', $uuid . ' | ' . $entropy . PHP_EOL, FILE_APPEND);
}

Using composer:

composer require ramsey/uuid ircmaxell/random-lib

@ramsey Results:

  • Micro Instance AmazonLinux (almost 70M)
$ sort uuids.txt | uniq -d
$ wc -l uuids.txt
69589819 uuids.txt

Entropies around 3000

  • Small Instance AmazonLinux (10M)
$ sort uuids.txt | uniq -d
$ wc -l uuids.txt
10063312 uuids.txt

Entropies around 3000

  • Medium Instance CentOS (10M)
# sort uuids.txt | uniq -d
# wc -l uuids.txt
10181234 uuids.txt

Entropies around 200 (too low, maybe because kernel 2.6?), but still no dups.

No duplicates on any of them. Using the following php:

<?php
require_once 'vendor/autoload.php';
while (1) {
    $uuid = \Ramsey\Uuid\Uuid::uuid4();
    $entropy = trim(file_get_contents('/proc/sys/kernel/random/entropy_avail'));

    file_put_contents('uuids.txt', $uuid . PHP_EOL, FILE_APPEND);
    file_put_contents('uuids-entropies.txt', $uuid . ' | ' . $entropy . PHP_EOL, FILE_APPEND);
}

Using composer:

composer require ramsey/uuid ircmaxell/random-lib
@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Nov 15, 2015

Owner

Thanks for doing that, @Lansoweb.

I wonder if there's a way to reduce the entropy on a system to see if we can create collisions. That would be an interesting test to try to reproduce what's being reported. It would also help show it might be the system that needs modification (i.e. increasing entropy).

Owner

ramsey commented Nov 15, 2015

Thanks for doing that, @Lansoweb.

I wonder if there's a way to reduce the entropy on a system to see if we can create collisions. That would be an interesting test to try to reproduce what's being reported. It would also help show it might be the system that needs modification (i.e. increasing entropy).

@Lansoweb

This comment has been minimized.

Show comment
Hide comment
@Lansoweb

Lansoweb Nov 15, 2015

@ramsey Just tried but i'm unable to change the entropy poolsize, maybe because it's a virtualized environment and some kernel features are locked.

Just checked, the poolsize on the CentOS is 4096, but it's a production system and maybe the pool was heavily used, so the low entropy_avail.

@ramsey Just tried but i'm unable to change the entropy poolsize, maybe because it's a virtualized environment and some kernel features are locked.

Just checked, the poolsize on the CentOS is 4096, but it's a production system and maybe the pool was heavily used, so the low entropy_avail.

@langemeijer

This comment has been minimized.

Show comment
Hide comment
@langemeijer

langemeijer Nov 15, 2015

What I have understood from the people that have taught me is that reduced entropy is unlikely to be a cause for collisions. Good pseudo random number generators generate sound statistically random numbers. Entropy, the secret sauce that is used as the (continous) input for a random generator reduces the predictability of the output, but doesn't affect the statistical randomness.

What I have understood from the people that have taught me is that reduced entropy is unlikely to be a cause for collisions. Good pseudo random number generators generate sound statistically random numbers. Entropy, the secret sauce that is used as the (continous) input for a random generator reduces the predictability of the output, but doesn't affect the statistical randomness.

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Nov 15, 2015

Owner

What would affect the statistical randomness? I don't think it's anything within the ramsey/uuid library, since we're relying on external genrators to generate the bytes

Owner

ramsey commented Nov 15, 2015

What would affect the statistical randomness? I don't think it's anything within the ramsey/uuid library, since we're relying on external genrators to generate the bytes

@Lansoweb

This comment has been minimized.

Show comment
Hide comment
@Lansoweb

Lansoweb Nov 15, 2015

@ramsey True. My tests were about validating that AWS instances behave as any other linux and this issue is not related to them specifically.

@ramsey True. My tests were about validating that AWS instances behave as any other linux and this issue is not related to them specifically.

@ircmaxell

This comment has been minimized.

Show comment
Hide comment
@ircmaxell

ircmaxell Nov 16, 2015

A flaw in the algorithm or a collision in the underlying hash function (Linux kernel uses sha1). Note that openssl on anything but windows doesn't use the kernels RNG, so it's using its own mixer.

Entropy would be a red herring.

Mixers work like this

                           [ Entropy ]
                                  ↓
[ State ]↔↔↔↔↔[ Mixer ]
     ↓                           ↑
[ Hash Function ]       ↑
     ↓                            ↑
[ Splitter ]  →  →  →  ↑
     ↓
$output

Or in a "class form pseudocode":

class CSPRNG {
    private $state;
    public function addEntropy(string $entropy) {
        $this->mix($entropy);
    }
    public function getBytes(): string {
        $hash = $this->hash($this->state);
        list ($return, $newState) = str_split($hash, strlen($hash)/2);
        $this->mix($newState);
        return $return;
    }
    private function mix(string $data) {
        $this->state = $this->hash($data . $this->state);
    }
    private function hash(string $data) : string {
        return hash('sha1', $data, true);
    }
}

So the only real source of "predictability" or collisions would come from the sha1 function being flawed (which it is, but not for this usage).

A flaw in the algorithm or a collision in the underlying hash function (Linux kernel uses sha1). Note that openssl on anything but windows doesn't use the kernels RNG, so it's using its own mixer.

Entropy would be a red herring.

Mixers work like this

                           [ Entropy ]
                                  ↓
[ State ]↔↔↔↔↔[ Mixer ]
     ↓                           ↑
[ Hash Function ]       ↑
     ↓                            ↑
[ Splitter ]  →  →  →  ↑
     ↓
$output

Or in a "class form pseudocode":

class CSPRNG {
    private $state;
    public function addEntropy(string $entropy) {
        $this->mix($entropy);
    }
    public function getBytes(): string {
        $hash = $this->hash($this->state);
        list ($return, $newState) = str_split($hash, strlen($hash)/2);
        $this->mix($newState);
        return $return;
    }
    private function mix(string $data) {
        $this->state = $this->hash($data . $this->state);
    }
    private function hash(string $data) : string {
        return hash('sha1', $data, true);
    }
}

So the only real source of "predictability" or collisions would come from the sha1 function being flawed (which it is, but not for this usage).

@wjzijderveld

This comment has been minimized.

Show comment
Hide comment
@wjzijderveld

wjzijderveld Dec 15, 2015

We are seeing collisions as well now. On a very small dataset (we generate < 300 a day :-/), so I would think it's something with the underlaying system.
2.6.32-504.16.2.el6.x86_64 and 2.6.32-504.8.1.el6.x86_64 both CentOS 6.7

Generating on the CLI doesn't cause collisions, a while back a tried to generate thru nginx, but no collisions there.
It seems that collisions don't happen for uuid's generated on the same day.

Our hosting has installed haveged on 1 machine, but that didn't seemed to have solved the problem, which makes sense if I understand your comment @ircmaxell? As openssl use their own system? We'll ask them if they can upgrade openssl, which is currently 1.0.1e-fips.

At this moment I don't think there is an issue in ramsey/uuid, but I still wanted to let you know :-)

We are seeing collisions as well now. On a very small dataset (we generate < 300 a day :-/), so I would think it's something with the underlaying system.
2.6.32-504.16.2.el6.x86_64 and 2.6.32-504.8.1.el6.x86_64 both CentOS 6.7

Generating on the CLI doesn't cause collisions, a while back a tried to generate thru nginx, but no collisions there.
It seems that collisions don't happen for uuid's generated on the same day.

Our hosting has installed haveged on 1 machine, but that didn't seemed to have solved the problem, which makes sense if I understand your comment @ircmaxell? As openssl use their own system? We'll ask them if they can upgrade openssl, which is currently 1.0.1e-fips.

At this moment I don't think there is an issue in ramsey/uuid, but I still wanted to let you know :-)

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Dec 15, 2015

Owner

This thread is scaring people from using this library, so I'd like to get to the bottom of what's causing these duplicates, even if it's not the fault of this library.

For those who are able to reproduce this, can you please dump the name of the generator that's being used to create the UUIDs that are duplicates? This might give us a good idea of where to look deeper into this issue.

Here's a modified version of @Lansoweb's script that will dump the generator used to a file:

<?php
require_once 'vendor/autoload.php';
while (1) {
    $uuid = \Ramsey\Uuid\Uuid::uuid4();
    $entropy = trim(file_get_contents('/proc/sys/kernel/random/entropy_avail'));
    $generator = get_class($uuid->getFactory()->getRandomGenerator());

    file_put_contents('uuids.txt', $uuid . PHP_EOL, FILE_APPEND);
    file_put_contents('uuids-entropies.txt', $uuid . ' | ' . $entropy . PHP_EOL, FILE_APPEND);
    file_put_contents('uuids-generators.txt', $uuid . ' | ' . $generator . PHP_EOL, FILE_APPEND);
}
Owner

ramsey commented Dec 15, 2015

This thread is scaring people from using this library, so I'd like to get to the bottom of what's causing these duplicates, even if it's not the fault of this library.

For those who are able to reproduce this, can you please dump the name of the generator that's being used to create the UUIDs that are duplicates? This might give us a good idea of where to look deeper into this issue.

Here's a modified version of @Lansoweb's script that will dump the generator used to a file:

<?php
require_once 'vendor/autoload.php';
while (1) {
    $uuid = \Ramsey\Uuid\Uuid::uuid4();
    $entropy = trim(file_get_contents('/proc/sys/kernel/random/entropy_avail'));
    $generator = get_class($uuid->getFactory()->getRandomGenerator());

    file_put_contents('uuids.txt', $uuid . PHP_EOL, FILE_APPEND);
    file_put_contents('uuids-entropies.txt', $uuid . ' | ' . $entropy . PHP_EOL, FILE_APPEND);
    file_put_contents('uuids-generators.txt', $uuid . ' | ' . $generator . PHP_EOL, FILE_APPEND);
}
@clphillips

This comment has been minimized.

Show comment
Hide comment
@clphillips

clphillips Jan 4, 2016

I'm also seeing duplicate with UUID version 5 (UPDATE: same applies to version 3 as well). This is on Windows:

$uuid = Uuid::uuid5(Uuid::NAMESPACE_DNS, 'domain.com');
echo $uuid->toString() . "\n";
echo get_class($uuid->getFactory()->getRandomGenerator()) . "\n";

Output:

975a4bf0-a690-5ea9-8469-b07f8978e4e3
Ramsey\Uuid\Generator\OpenSslGenerator
975a4bf0-a690-5ea9-8469-b07f8978e4e3
Ramsey\Uuid\Generator\OpenSslGenerator
975a4bf0-a690-5ea9-8469-b07f8978e4e3
Ramsey\Uuid\Generator\OpenSslGenerator
975a4bf0-a690-5ea9-8469-b07f8978e4e3
Ramsey\Uuid\Generator\OpenSslGenerator

I'll note that UUID4, however, does not produce duplicates:

echo Uuid::uuid4()->toString() . "\n";
echo Uuid::uuid4()->toString() . "\n";
echo Uuid::uuid4()->toString() . "\n";
echo Uuid::uuid4()->toString() . "\n";
13eaa288-97e0-4446-8dba-31d883c7318e
6a929065-ecc9-496a-aef8-f16b52a5b480
2eb338c0-eaf6-46d3-b659-20fc04c5f7ef
53f0991c-aea5-4de6-9f10-1663d7f0cd27

I'm also seeing duplicate with UUID version 5 (UPDATE: same applies to version 3 as well). This is on Windows:

$uuid = Uuid::uuid5(Uuid::NAMESPACE_DNS, 'domain.com');
echo $uuid->toString() . "\n";
echo get_class($uuid->getFactory()->getRandomGenerator()) . "\n";

Output:

975a4bf0-a690-5ea9-8469-b07f8978e4e3
Ramsey\Uuid\Generator\OpenSslGenerator
975a4bf0-a690-5ea9-8469-b07f8978e4e3
Ramsey\Uuid\Generator\OpenSslGenerator
975a4bf0-a690-5ea9-8469-b07f8978e4e3
Ramsey\Uuid\Generator\OpenSslGenerator
975a4bf0-a690-5ea9-8469-b07f8978e4e3
Ramsey\Uuid\Generator\OpenSslGenerator

I'll note that UUID4, however, does not produce duplicates:

echo Uuid::uuid4()->toString() . "\n";
echo Uuid::uuid4()->toString() . "\n";
echo Uuid::uuid4()->toString() . "\n";
echo Uuid::uuid4()->toString() . "\n";
13eaa288-97e0-4446-8dba-31d883c7318e
6a929065-ecc9-496a-aef8-f16b52a5b480
2eb338c0-eaf6-46d3-b659-20fc04c5f7ef
53f0991c-aea5-4de6-9f10-1663d7f0cd27

ramsey added a commit that referenced this issue Mar 15, 2016

Drop OpenSSL support and use paragonie/random_compat
Fixes issue #80 for the 2.x series

ramsey added a commit that referenced this issue Mar 15, 2016

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Mar 15, 2016

Owner

All right—any takers on testing these changes to see if this resolves the collision issue?

For both the 2.x and 3.x series, I have required the without-openssl branch of paragonie/random_compat. See paragonie/random_compat#93.

After receiving positive feedback from those who have been experiencing collisions, I'll wait for @paragonie-scott to tag a release of paragonie/random_compat, and then I'll release versions 2.9.0 and 3.3.0 of ramsey/uuid.

To test the changes, you'll need to set "minimum-stability" to "dev" in your composer.json.

If using the 2.x series, install from Composer with:

composer require ramsey/uuid=dev-2.x/random_compat

If using the 3.x series, install from Composer with:

composer require ramsey/uuid=dev-3.x/random_compat
Owner

ramsey commented Mar 15, 2016

All right—any takers on testing these changes to see if this resolves the collision issue?

For both the 2.x and 3.x series, I have required the without-openssl branch of paragonie/random_compat. See paragonie/random_compat#93.

After receiving positive feedback from those who have been experiencing collisions, I'll wait for @paragonie-scott to tag a release of paragonie/random_compat, and then I'll release versions 2.9.0 and 3.3.0 of ramsey/uuid.

To test the changes, you'll need to set "minimum-stability" to "dev" in your composer.json.

If using the 2.x series, install from Composer with:

composer require ramsey/uuid=dev-2.x/random_compat

If using the 3.x series, install from Composer with:

composer require ramsey/uuid=dev-3.x/random_compat

@paragonie-scott paragonie-scott referenced this issue in paragonie/random_compat Mar 16, 2016

Closed

What to do about OpenSSL? #96

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 16, 2016

The discussion in paragonie/random_compat#96 will ultimately decide how we proceed, but it's clear that OpenSSL is not to be treated as cryptographically secure.

The discussion in paragonie/random_compat#96 will ultimately decide how we proceed, but it's clear that OpenSSL is not to be treated as cryptographically secure.

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Mar 17, 2016

Owner

I've bumped dev-2.x/random_compat and dev-3.x/random_compat to use paragonie/random_compat at dev-master, in preparation for its next release. All tests are passing, and this shouldn't affect behavior in any way, but I would love to hear feedback from anyone experiencing collisions about whether this resolves the problem for you.

Thanks!

Owner

ramsey commented Mar 17, 2016

I've bumped dev-2.x/random_compat and dev-3.x/random_compat to use paragonie/random_compat at dev-master, in preparation for its next release. All tests are passing, and this shouldn't affect behavior in any way, but I would love to hear feedback from anyone experiencing collisions about whether this resolves the problem for you.

Thanks!

@paragonie-scott paragonie-scott referenced this issue in paragonie/random_compat Mar 20, 2016

Closed

no suitable CSPRNG 1.3.0 #99

@ramsey

This comment has been minimized.

Show comment
Hide comment
@ramsey

ramsey Mar 22, 2016

Owner

Versions 2.9.0 and 3.3.0 are now released with a dependency on paragonie/random_compat at version ^1.0|^2.0 (which should help ease the upgrade for all users).

This update fixes the collision issues reported in this thread.

All users are advised to upgrade ramsey/uuid to either version 2.9.0 or 3.3.0 immediately.

Owner

ramsey commented Mar 22, 2016

Versions 2.9.0 and 3.3.0 are now released with a dependency on paragonie/random_compat at version ^1.0|^2.0 (which should help ease the upgrade for all users).

This update fixes the collision issues reported in this thread.

All users are advised to upgrade ramsey/uuid to either version 2.9.0 or 3.3.0 immediately.

@ramsey ramsey closed this Mar 22, 2016

@mathieuk

This comment has been minimized.

Show comment
Hide comment
@mathieuk

mathieuk Mar 23, 2016

I've been doing some testing on just how bad things would be with openssl_pseudo_random_bytes and have been unable to generate any duplicates yet, having generated ~ 40M openssl_pseudo_random_bytes(16) and uuid::uuid4() samples in a script that mimics apache2 prefork mpm behaviour. That struck me as odd, seeing as @giorgiosironi reports hundreds of collisions on ~1M generated values. This was on PHP 5.5 with openssl 1.0.1f.

Then I did some more reading and this article linked from the openssl wiki article describes how pid wraparound was an issue for OpenSSL at that time (2013) and that time was added as a seed next to the pid to mitigate that. You can see that being added in this commit on openssl on 20 sept 2013.

Now, @giorgiosironi reported using openssl 1.0.1 built on May 2012 so he wouldn't have that mix-time-into-the-pool change in openssl.

Maybe that explains why he is/was seeing so much collisions with openssl_pseudo_random_bytes()?

I've been doing some testing on just how bad things would be with openssl_pseudo_random_bytes and have been unable to generate any duplicates yet, having generated ~ 40M openssl_pseudo_random_bytes(16) and uuid::uuid4() samples in a script that mimics apache2 prefork mpm behaviour. That struck me as odd, seeing as @giorgiosironi reports hundreds of collisions on ~1M generated values. This was on PHP 5.5 with openssl 1.0.1f.

Then I did some more reading and this article linked from the openssl wiki article describes how pid wraparound was an issue for OpenSSL at that time (2013) and that time was added as a seed next to the pid to mitigate that. You can see that being added in this commit on openssl on 20 sept 2013.

Now, @giorgiosironi reported using openssl 1.0.1 built on May 2012 so he wouldn't have that mix-time-into-the-pool change in openssl.

Maybe that explains why he is/was seeing so much collisions with openssl_pseudo_random_bytes()?

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Mar 23, 2016

@mathieuk most probably you're correct and 1.0.1f has the issue fixed.

samdark commented Mar 23, 2016

@mathieuk most probably you're correct and 1.0.1f has the issue fixed.

@tom--

This comment has been minimized.

Show comment
Hide comment
@tom--

tom-- Mar 23, 2016

@mathieuk can you share your scripts for trying to recreate the collisions?

I tried and failed with this. I tried with a current OpenSSL and with 0.9.8zsomething but no luck.

Note that mixing in time doesn't make it safe but does make it harder to test.

tom-- commented Mar 23, 2016

@mathieuk can you share your scripts for trying to recreate the collisions?

I tried and failed with this. I tried with a current OpenSSL and with 0.9.8zsomething but no luck.

Note that mixing in time doesn't make it safe but does make it harder to test.

@mathieuk

This comment has been minimized.

Show comment
Hide comment
@mathieuk

mathieuk Mar 24, 2016

Here you go, @tom--: https://gist.github.com/mathieuk/63cc6479734b820340b6 . They're quite simple. I agree that time doesn't make it safe for crypto. I'm not trying to defend the use of openssl_pseudo_random_bytes. I'm just trying to understand the issue :).

Also make note of the remarks under "It’s me again, the Debian OpenSSL bug" in http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ . If the buffer isn't null initialised we probably won't be getting any collisions easily.

Here you go, @tom--: https://gist.github.com/mathieuk/63cc6479734b820340b6 . They're quite simple. I agree that time doesn't make it safe for crypto. I'm not trying to defend the use of openssl_pseudo_random_bytes. I'm just trying to understand the issue :).

Also make note of the remarks under "It’s me again, the Debian OpenSSL bug" in http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ . If the buffer isn't null initialised we probably won't be getting any collisions easily.

@mathieuk

This comment has been minimized.

Show comment
Hide comment
@mathieuk

mathieuk Mar 24, 2016

I added the time component to my test: resetting the time to a fixed time every 500 spawned processes. That gave me duplicates with php 5.6.19 and openssl 1.0.1e on debian wheezy. The latest debian wheezy version of openssl (1.0.1e-2+deb7u20) does not add that uninitialized buffer of memory to the pool as described in the blogpost.

I added the time component to my test: resetting the time to a fixed time every 500 spawned processes. That gave me duplicates with php 5.6.19 and openssl 1.0.1e on debian wheezy. The latest debian wheezy version of openssl (1.0.1e-2+deb7u20) does not add that uninitialized buffer of memory to the pool as described in the blogpost.

@tom--

This comment has been minimized.

Show comment
Hide comment
@tom--

tom-- Mar 24, 2016

thanks @mathieuk. Could you update your gist with the time-setting? (fwiw, you can clone a gist and push to it.)

My interest is also to be able to demonstrate the various conditions under which different OpenSSL versions are liable to this forking stuff.

I just want it on the record for anyone reading this discussion: there's nothing random about PID and nothing random about time. Mixing these in might be worse than useless if doing so masks a security bug.

tom-- commented Mar 24, 2016

thanks @mathieuk. Could you update your gist with the time-setting? (fwiw, you can clone a gist and push to it.)

My interest is also to be able to demonstrate the various conditions under which different OpenSSL versions are liable to this forking stuff.

I just want it on the record for anyone reading this discussion: there's nothing random about PID and nothing random about time. Mixing these in might be worse than useless if doing so masks a security bug.

@mathieuk

This comment has been minimized.

Show comment
Hide comment
@mathieuk

mathieuk Mar 25, 2016

Done, https://gist.github.com/mathieuk/63cc6479734b820340b6. Also added some details about how I am running this.

The following situations may result in duplicates:

  • PHP built with plain OpenSSL earlier than 1.0.1f (first release after the time fix) only needs wrapping pid counter for duplicates to occur.
  • PHP built with OpenSSL with Debian (Wheezy, haven't looked at Jessie) patches, including the time fix. Needs wrapping pid counter and matching time for duplicates to occur.

It seems to me that PHP could help the situation a bit by re-initialising the openssl RNG on the first call to openssl_pseudo_random_bytes and other dependent functions. Apache seems to do such a thing with RAND_seed() on each SSL request.

Done, https://gist.github.com/mathieuk/63cc6479734b820340b6. Also added some details about how I am running this.

The following situations may result in duplicates:

  • PHP built with plain OpenSSL earlier than 1.0.1f (first release after the time fix) only needs wrapping pid counter for duplicates to occur.
  • PHP built with OpenSSL with Debian (Wheezy, haven't looked at Jessie) patches, including the time fix. Needs wrapping pid counter and matching time for duplicates to occur.

It seems to me that PHP could help the situation a bit by re-initialising the openssl RNG on the first call to openssl_pseudo_random_bytes and other dependent functions. Apache seems to do such a thing with RAND_seed() on each SSL request.

@tom--

This comment has been minimized.

Show comment
Hide comment
@tom--

tom-- Mar 25, 2016

@mathieuk nice! I look forward to exploring this myself.

tom-- commented Mar 25, 2016

@mathieuk nice! I look forward to exploring this myself.

@paragonie-scott paragonie-scott referenced this issue in defuse/php-encryption Mar 26, 2016

Closed

Use random_bytes() for key generation! #68

@mathieuk

This comment has been minimized.

Show comment
Hide comment
@mathieuk

mathieuk Mar 29, 2016

Posted a bugreport and an attempt at improving things: https://bugs.php.net/bug.php?id=71915

Posted a bugreport and an attempt at improving things: https://bugs.php.net/bug.php?id=71915

DRvanR pushed a commit to OpenConext/OpenConext-engineblock that referenced this issue Apr 5, 2016

@DRvanR DRvanR referenced this issue in OpenConext/OpenConext-engineblock Apr 5, 2016

Merged

Updated ramsey/uuid to prevent UUID collisions #286

@relaxnow relaxnow referenced this issue in robrichards/xmlseclibs Apr 12, 2016

Open

Avoid insecure openssl_random_pseudo_bytes #100

@paragonie-scott paragonie-scott referenced this issue in paragonie/random_compat Apr 14, 2016

Closed

Global namespace collision "Error" #104

@paragonie-scott paragonie-scott referenced this issue in cartalyst/sentinel Apr 25, 2016

Merged

random_compat version update #232

@Rican7 Rican7 referenced this issue in robinpowered/php-ntlm Apr 25, 2016

Closed

Remove support for OpenSSL random byte generation #7

@paragonie-scott paragonie-scott referenced this issue in wlox/wlox-auth May 25, 2016

Closed

Completely insecure cryptography #8

@paragonie-scott paragonie-scott referenced this issue in paragonie/random_compat Sep 9, 2016

Closed

Which version should we use ? #116

danlamanna added a commit to Kitware/CDash that referenced this issue Nov 21, 2016

danlamanna added a commit to Kitware/CDash that referenced this issue Nov 21, 2016

@ramsey ramsey added the bug label Feb 23, 2017

@paragonie-scott paragonie-scott referenced this issue in ircmaxell/RandomLib Aug 13, 2017

Open

Deprecated warnings on PHP 7.1 #55

@paragonie-scott paragonie-scott referenced this issue in defuse/php-encryption Aug 23, 2017

Closed

Little explanation + bugfix #358

derekmarcotte added a commit to derekmarcotte/PHP-PasswordLib that referenced this issue Oct 19, 2017

Added OpensslRandPseudo random source.
This uses openssl_random_pseudo_bytes.  This is suggested for use only with
with php5-openssl compiled against LibreSSL:

  OpenSSL copying RNG state on fork:
    ramsey/uuid#80 (comment)
  Fixed in LibreSSL:
    http://opensslrampage.org/post/91910269738/fix-for-the-libressl-prng-issue-under-linux

Additionally, CVE-2015-8867 was fixed only in versions 5.6.12, 5.5.28,
5.4.44 and above:

  https://bugs.php.net/bug.php?id=70014
  http://www.php.net/ChangeLog-5.php

CVE-2015-8867 does not affect versions compiled against LibreSSL.

For these reasons, it only is considered a LOW source of randomness,
unless it is compiled against LibreSSL.

The reason for this to exist at all is because of problems with the
nature of /dev/urandom.  For example, if we cannot open or read the
file.  openssl_random_pseudo_bytes should never fail.

@derekmarcotte derekmarcotte referenced this issue in ircmaxell/PHP-PasswordLib Oct 19, 2017

Open

Added OpensslRandPseudo random source. #25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment