Bug #70744 [Opn]: random_bytes() should not use linc arc4random

From: 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

« previous php.bugs (#196711) next »