Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94429
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.160 cause and error)
MIME-Version: 1.0
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>
In-Reply-To: <CA+kxMuTEtx5Euii1XzF_rUztNAOSLO2VCWCBwbYbmv=JPMDsJQ@mail.gmail.com>
Date: Fri, 08 Jul 2016 04:56:34 +0000
Message-ID: <CANUQDCi6J8xme_No39qHzMhLRoZoK9sn8pJVAaq98mgkXXSZWw@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>, Leigh <leight@gmail.com>
Cc: Dan Ackroyd <danack@php.net>, PHP internals <internals@lists.php.net>, 
	Pierre Joye <pierre.php@gmail.com>, Stanislav Malyshev <smalyshev@gmail.com>, 
	Yasuo Ohgaki <yohgaki@ohgaki.net>
Content-Type: multipart/alternative; boundary=089e0122ebe23ca476053718a195
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing
From: me@kelunik.com (Niklas Keller)

--089e0122ebe23ca476053718a195
Content-Type: text/plain; charset=UTF-8

>
> > 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.
>

Sure, but it's the right way. Just like random_bytes having no fallback.

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.
>

Nobody talks about buying new hardware. It usually happens due to bad
system setup, such as blocking access to /dev/random.

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.
>
> Yasuo wrote:
> > Some of us worried about CSPRNG state exposure. I'm wondering how many
> > of you will vote in favor if I change the RFC to use hash functions
> > optionally.
>
> Yes.
>
> Though as I said before, I think changing session.use_strict_mode
> should be a separate decision, and it's one I support doing.
>
> cheers
> Dan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0122ebe23ca476053718a195--