Bug #70744 [Opn]: random_bytes() should not use linc arc4random
| From: | leigh@php.net | Date: | Tue, 20 Oct 2015 17:29:43 +0000 |
| Subject: | Bug #70744 [Opn]: random_bytes() should not use linc arc4random | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-196711@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=70744&edit=1
ID: 70744
Updated by: leigh@php.net
Reported by: fsb at thefsb dot org
Summary: random_bytes() should not use linc arc4random
Status: Open
Type: Bug
Package: *Encryption and hash functions
Operating System: All except Windows
PHP Version: 7.0.0RC5
Block user comment: N
Private report: N
New Comment:
Hey fsb,
I did quite a bit of research before including arc4random as an option in this function. I'll
detail what I am aware of, please correct me if I'm wrong.
The weaknesses in RC4 revolve around biases in the keystream or recovery of the initial bytes -
we're not using the keystream for a stream cipher so we can ignore any kind of plaintext
recovery attacks.
Most of these weaknesses relate to the first few bytes of the stream, some the first 256 byes (from
memory). Biases have been observed in longer keystreams too - from 2^24 to 2^25 bytes I believe.
The arc4random implementation in BSD (and OSX) both discards the first few kilobytes of the
keystream, and re-keys regularly - before the 2^24 threshold.
In order to observe biases, you need to observe the uninterrupted keystream. As the keystream shared
between all consumers, it is unlikely that you will observe a complete stream, and you also have no
idea when a rekey will happen.
I would go as far as saying the chance of observing any meaningful bias is negligible.
If you have seen research that suggests the BSD implementation with its mitigations (rather than the
known-broken vanilla RC4) is still unfit for a CSPRNG I'd really like to see it.
Previous Comments:
------------------------------------------------------------------------
[2015-10-20 16:48:51] fsb at thefsb dot org
Fwiw, asking in Freenode #openbsd this morning:
11:43 tom[] is there a reliable way for a program to determine if the linked libc arc4random
(assuming there is one) is ChaCha20 or heirloom 96 ARC4?
11:47 Straylight tom[]: if the OS version is >= 5.5 (uname(3) should tell you that?), then
it's chaha
11:48 tom[] Straylight: yes, but then this eventually has to evolve into a small database for
all the BSDs
11:49 Straylight tom[]: If you're asking for a mechanism that works across any possible BSD
derivative, then it doesn't exist
In which I am tom[] and time is UTC-04:00. I don't know who is Straylight.
[Sorry again for suggesting in OP that NetBSD introduced ChaCha20. It was OpenBSD in 2013.]
------------------------------------------------------------------------
[2015-10-20 14:57:28] fsb at thefsb dot org
CORRECTION: OpenBSD since 5.5 uses ChaCha20.
But random_bytes() use of arc4random_buf() remains unsafe.
------------------------------------------------------------------------
[2015-10-19 22:04:57] fsb at thefsb dot org
Description:
------------
ARC4 is known to be unsafe for use either as a stream cipher or a CSPRNG. You can read about it on
Wikipedia and elsewhere.
As far as I can tell, until recently, all implementations of the libc arc4random functions are based
on David Mazieres 1996 implementation of ARC4. In November 2014, NetBSD replaced the cipher
underneath libc's arc4random API with ChaCha20, a modern stream cipher currently considered
safe. But this change hasn't made it into a NetBSD release yet. OS X, FreeBSD and OpenBSD have
not yet incorporated NetBSD's source code change and I don't know if they will. So for the
time being we have to assume that libc arc4random is ARC4 cipher and therefore unsafe.
This code branch should be removed.
https://github.com/php/php-src/blob/php-7.0.0RC5/ext/standard/random.c#L91
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=70744&edit=1