Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94431
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.66 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuTEtx5Euii1XzF_rUztNAOSLO2VCWCBwbYbmv=JPMDsJQ@mail.gmail.com>
References: <CAGa2bXaSkozJLLtycujwmHyas9TofRw5s6JzG0EQQvPyU0pxNQ@mail.gmail.com>
 <CAGa2bXZ=DiqQ4PozYntvGApZHdkjWyTBQhk_Udy5Y3_m0ry9Lw@mail.gmail.com>
 <a32232d3-006b-a7c2-0aa8-7f44509dfe69@gmail.com> <CAGa2bXa3o4FzQDGyU+=XHWoH59QjTJdJcjwch4=VdUUC7ZsD=w@mail.gmail.com>
 <CAEZPtU5RRGbUXJE7cHd2LuUmF5hiGDJAhGNKZ+_nRj1d+pHkZA@mail.gmail.com>
 <CAPwsocHU4Dc5YLMq_vfJsvXQseH7es4baMh-_pNJFf7aB3bKyg@mail.gmail.com> <CA+kxMuTEtx5Euii1XzF_rUztNAOSLO2VCWCBwbYbmv=JPMDsJQ@mail.gmail.com>
Date: Fri, 8 Jul 2016 09:40:04 +0100
Message-ID: <CAPwsocGmfD5y8uUhB8Mu5yyomnoHd2+uXLc8XwbKip_b=G_HcQ@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	Dan Ackroyd <danack@php.net>, PHP internals <internals@lists.php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing
From: leight@gmail.com (Leigh)

On 7 July 2016 at 21:33, Dan Ackroyd <danack@basereality.com> wrote:
>> I think we need to drop the concerns about exposing "RNG state".
>>
>> If these are weak RNGs on your system, YOUR SYSTEM is broken.
>
> Telling people that their system is broken isn't going to be
> comforting to the people it happens to.

Of course it isn't. If I find out suddenly that /dev/urandom is
somehow predictable I would be incredibly uncomfortable. However the
least of my worries would be PHPs session id generation.

> There are always bugs in software and hardware. At some point it is
> almost inevitable that there will be some information leak through
> exposing the random numbers directly. Just telling people that their
> system is broken and they need to buy need hardware immediately,
> rather than just being able to re-enable hashing seems a bad choice.

I feel like we're back to the discussions around random_bytes() again.

The random number generators being used here are designated CS for a
reason. They are not like deterministic RNGs where you can give them
simple seed and produce the same set of outputs. They draw on
environmental noise for additional entropy and where appropriate they
reseed regularly, far before any useful statistical information can be
gathered.

In the case of urandom it actually performs a SHA1 on its pool,
CryptGenRandom mixes in data that has been MD4 hashed, arc4random_buf
is literally a stream cipher. These are well maintained and vetted
systems. An extra round of hashing is simply unnecessary overhead.

> But even without accidental bugs, the scenario I am remain concerned
> with is when a piece of hardware or software is compromised by a
> sophisticated attacker, (hello NSA!) and the 'random' numbers
> generated have some subtle pattern to them. To almost everyone, the
> random numbers generated would still look random. But to the
> organisation that compromised the system, and so knows the algorithm
> that is leaving traces in the random sequences, exposing the random
> numbers directly to the outside world would be an obvious but almost
> untraceable line of attack on the system.

I know it's easy to say: If your system has been compromised you have
bigger problems. But this is pretty much the fact of it. If someone
has the ability to make your system CSPRNG predictable, they can
almost certainly get anything else they want from the system anyway
without resorting to that.