Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 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 11:00:43 +0900
Message-ID: <CAGa2bXaRnrheTnrQ8JcRhCwHL-wSpqvDsv=kCMXO_XTnxMh-ow@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: Leigh <leight@gmail.com>, Pierre Joye <pierre.php@gmail.com>, 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: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Dan,

On Fri, Jul 8, 2016 at 5:33 AM, 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.
>
> 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.
>
> 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.
>
> Hashing should still obfuscate any subtle patterns in the random
> number generation, and so give some protection against comprised
> chip-set/firmware. If users choose to continue to want the extra
> security of hashing, at the cost of slightly slower session ID
> generation we shouldn't removed that from them.

I understand concern and I would not argue against that hashing should
still obfuscate PRNG state.

The patch proposed/session module has mitigations
 - Read extra bytes from RPNG to hide raw PRNG state
  (This should be good enough mitigation for usable CSPRNG)
 - In case PRNG generates the same session IDs repeatedly, it
terminate execution with E_ERROR/E_RECOVERABLE_ERROR.
  (This shouldn't happen with good CSPRNG)

Above mitigations should be good enough for CSRPNG applications.
System with seriously broken CSPRNG should not be used anyway. IMO.

Vote requires 2/3 in favor. Current vote is 6 vs 3.
If this RFC declined, I'll prepare patch that has optional hashing.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net