On 10/28/15 6:46 PM, Anatol Belski wrote:
-----Original Message-----
From: Leigh [mailto:lei...@gmail.com]
Sent: Wednesday, October 28, 2015 11:14 PM
To: Anatol Belski <anatol....@belski.net>
Cc: php-...@lists.php.net; PHP Internals <internals@lists.php.net>
Subject: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Remove
arc4random: ext/standard/config.m4 ext/standard/random.c
On 28 October 2015 at 09:51, Anatol Belski <anatol....@belski.net> wrote:
Yeah, I was only talking about those two OS versions that are known
for sure to have proper implementations. Even that is a smaller
community than fe Linux, IMHO no reason to handicap users, especially
as the corresponding codes are present and would need just a condition
to extend. It's not that anyone would judge what is secure, but based
on the fact that ChaCha is already used, is being widely adopted and there's no
evidence of any flaws.
Probably when it is implemented in more places like other more popular
BSD and Solaris forks, we'll see some patches to PHP anyway.
Are you saying you would like me to add arc4random back in,
conditionally
for those OS versions only?
I'll test on VMs obviously, but it looks like it should only require:
#if defined(__OpenBSD__) || defined(__NetBSD__) # include <sys/param.h>
#endif
#if HAVE_DECL_ARC4RANDOM_BUF && ((defined(__OpenBSD__) && OpenBSD
=
201405) || (defined(__NetBSD__) && __NetBSD_Version__ >= 700000001))
arc4random_buf(bytes, size);
#elif
...
201405 maps to the 5.5 release date.
Yeah, I'd suggest the old code to stay under the new conditions. As per current
info an improved arc4random implementation is to appear in more OSes, thus not
losing this code is also future open. Except someone can point out a real issue
with ChaCha20, the time for the investigations should not have been spent for
nothing.
The name arc4random is confusing. It refers to a stdlib API that was
originally named after the ARC4 cipher that its generator was based on.
arc4random appears in all BSDs that I looked at and in libbsd, which you
can use on Linux, and has been ported to other platforms less relevant
to PHP.
There are three areas of concern:
1. The ARC4 cipher itself.
ARC4 has some biases that you wouldn't want from a decent CSPRNG. But,
as Leigh pointed out to me, arc4random has workarounds that render it
trustworthy. While it remains a good generator, ARC4 is being phased out
in general and it makes sense therefore to replace it in arc4random too
so that people don't flip out, like I did when I saw it.
ChaCha20 seems to be where a lot of things are heading for a
replacement, for both stream cipher and random generator, and I don't
think it is generally considered too new to trust.
So I think either the old or the new generator is fine for PHP.
2. Seeding reliability.
All arc4random implementations try to seed (stir as they call it) the
generator from kernel randomness. Some older arc4random implementations
have branches to cope with failure to read kernel randomness that,
without warning, stir in non-random numbers (PID and time) instead. In
OpenBSD 5.5+ it cannot happen because its getentropy() syscall cannot
fail. In NetBSD 7.0+, the process abort()s in this branch. In current
FreeBSD and OS X, the old non-random stirring remains.
This, in my opinion, is serious and only these new OpenBSD and NetBSD
arc4randoms are suitable for PHP 7.0.
3. arc4random puts a generator in the user process.
This is much more controversial. Some people (Anthony F. for one and
myself until recently) argue that a generator algorithm in the user
process degrades security. It must in any case be downstream of the
kernel source and therefore cannot compensate for any problems in using
kernel randomness. Moreover, it adds another point of failure (a place
where there might be bugs, like OpenSSL's RNG bugs). And finally, since
the downstream generator is in the user process rather than protected
kernel memory, it's easier for an attacker to learn the generator's
state and thus predict future outputs.
Others, including Dan Bernstein[1] and the OpenBSD crowd[2], argue that
the later is theoretical rather than a practical vulnerability because
if an attacker can read your memory then your crypto system is a total
fail regardless where you get random numbers from.
That's how we got to Leigh's question: Do we make arc4random conditional
on specific versions or take it out altogether? If that were the choice
I'd probably take it out because few people deploy PHP on OpenBSD or NetBSD.
But as an alternative, I made the proposal that, rather than linking
arc4random conditionally if the compile-time system is a recent OpenBSD
or NetBSD, we bundle the OpenBSD libc and libcrypto sources with PHP.
This is because the OpenBSD sources include ports for eight (8) other
operating sytstems[3]. This circumvents the crummy old arc4randoms out
there and the perpetual reading of kernel randomness as well as
providing code for getting kernel randomness on all these OSs. It struck
me as an interesting idea.
But Anthony doesn't like arc4random in any version for the reasons I
mentioned under 3. and said so with enough force that I had to back down.
Tom
[1] from http://blog.cr.yp.to/20140205-entropy.html
There are also people asserting that it's important for RNGs to provide
"prediction resistance" against attackers who, once upon a time, saw the
entire RNG state. But if the attacker sees the RNG state that was used
to generate your long-term SSL keys, long-term PGP keys, etc., then what
exactly are we gaining by coming up with unpredictable random numbers in
the future? I'm reminded of a Mark Twain quote:
> Behold, the fool saith, "Put not all thine eggs in the one
basket"—which is but a manner of saying, "Scatter your money and your
attention;" but the wise man saith, "Put all your eggs in the one basket
and—WATCH THAT BASKET."
We obviously need systems that can maintain confidentiality of our
long-term keys. If we have such systems, how is the attacker supposed to
ever see the RNG state in the first place? Maybe "prediction resistance"
can be given a theoretical definition for an isolated RNG system, but I
don't see how it makes any sense for a complete cryptographic system.
[2] Hackfest 2014: Theo de Raadt presented "arc4random - randomization
for all occasions" https://www.youtube.com/watch?v=aWmLWx8ut20
[3] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/crypto/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
