Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98031
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: <0D26A03B-6BEB-4730-8E4B-0F7D6835E683@thefsb.org>
References: <0D26A03B-6BEB-4730-8E4B-0F7D6835E683@thefsb.org>
Date: Mon, 30 Jan 2017 10:08:23 +0900
Message-ID: <CAGa2bXZYStrud9MWya-680Z457T1i-a2F5u-AXtaNvkTdMEZtQ@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: "internals@lists.php.net" <internals@lists.php.net>, =?UTF-8?Q?Lauri_Kentt=C3=A4?= <lauri.kentta@gmail.com>, 
	Leigh <leight@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c0641602a7bf20547457653
Subject: Re: [PHP-DEV] Re: Improving mt_rand() seed
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--94eb2c0641602a7bf20547457653
Content-Type: text/plain; charset=UTF-8

Hi Tom,

On Mon, Jan 30, 2017 at 1:22 AM, Tom Worster <fsb@thefsb.org> wrote:

> On 1/28/17 4:32 PM, Yasuo Ohgaki wrote:
>
> Could you give some examples?
>
> I'm not sure what kind of IoT devices/OS that support PHP do not have
> CSPRNG.
>
> I'm sorry, my reply ended up with subject "Re: internals Digest 27 Jan
> 2017 10:58:15 -0000 Issue 4425". My fault. I'll copy it here...
>
> There are two problems. One is embedded OSs with crummy RNGs
> <http://samvartaka.github.io/cryptanalysis/2017/01/03/33c3-embedded-rngs>.
>
> The other is any OS in a "low-entropy environment", fancy-talk for the
> situation when the OS's techniques for gathering "noise" from devices are
> frustrated by their absence, or little to no activity on those devices, or
> the activity not being random.
>
> I don't want to get into an argument about on which IoT Things you might
> find PHP. But we know its growing fast, the Things are significant in
> botnets
> <https://krebsonsecurity.com/2016/09/krebsonsecurity-hit-with-record-ddos/>,
> and that the Things often come with a web server for admin. It's not
> unreasonable to use PHP+SQLite to admin a Linux-based baby monitor, for
> example.
>

Generating CS random is not simple as in the document you mentioned.

"secure randomness is ideally provided as a system service." I agree this
statement. Systems support complex softwares like PHP should have CSPRNG.
As far as I understand, all IoT devices that support PHP at least have
working CSPRNG.

"This last issue also means that most embedded OSes that do implement a
CSPRNG only implement a non-blocking interface (eg. the /dev/urandom
interface on Unix-like systems) in order to prevent insufficient entropy
from holding up cryptographic operations"

Systems like IoT may not have TRNG and proper reseeding. Therefore,
"random" values have risk to be known to attackers. e.g. Some OSes CSPRNG
use RC4 for /dev/urandom. RC4 is known be vulnerable, but RC4 is still
considered secure if first part of stream is discarded. However, we cannot
guarantee 100% secureness due to the fact that RC4 is stream cipher/RC4's
simplicity.

Therefore, application developers are better to have additional care even
for CSPRNG. For example, current session module read CSPRNG random value
and generate session ID directly. Session module reads at least extra 64
bytes from CSPRNG to mitigate leaked CSPRNG state risk.

We need such caution for CSPRNG, but I suppose we don't have to worry about
CSPRNG availability because it should be there and if it cannot be used,
it's system a problem, not PHP issue. We don't care if data read from
memory is broken or not. CSPRNG availability is the same.


> OSes can provide CSPRNG w/o hardware based RNG. Security on IoT matters
> a lot, especially for IoT that supports PHP. CSPRNG features are in PHP
> core
> already. Secure PHP scripts wouldn't work anyway on such devices anyway.
> e.g. generating nonce or like.
>
> Correct. But we're talking about mt_rand() and therefore not about crypto.
> Apps that used it *correctly*, i.e. that did not relying on its output
> being unpredictable, will stop working if you make mt_rand() fail on these
> systems.
>
> It's a policy that selects competent developers that understand mt_rand()
> for greatest punishment.
>
I will change my opinion if there is unignorable breakage by CSPRNG usage.

IMO, if users really need working mt_rand() w/o CSPRNG, they should write
code like

mt_srand((int)lcg_value() * 10000000000);
mt_rand();

Vast majority of PHP users should enjoy better random value. They should
not be disturbed by very few users that use system lacking fundamental
security related service, i.e. CSPRNG. IMO.

Additional single line PHP code shouldn't be difficult for any users.

> Issues are
> - Current mt_rand() is not fully exploited. It wastes more than 99% of its
> random cycle.
>
> This was discussed in Aug last year and dropped.
>
I didn't notice the discussion, let's discuss again.

It does not make sense to discard more than 99% of cycle. In addition, MT
rand reference implementation is capable to initialize whole state buffer,
why we shouldn't have it?


>    - Current uniqid()'s entropy is extremely poor and there is fair
>    chances for collisions.
>
> I don't much care about uniqid().
>
> Question is
> - Are we going to keep these poor behaviors as PHP spec/standard forever
> or not.
>
> idk.
>
> My only argument in this is to disagree with you that it's ok to change
> these functions so they don't work in situations in which they did before.
> You can improve their seeding without doing that. Just don't make them fail
> when the improved seeding fails.
>
> Apart from that, I don't mind you flogging these two dead horses.
>
My point is described in previous sentence.

Vast majority of PHP users should enjoy better random value. They should
not be disturbed by very few users that use system lacking fundamental
security related service, i.e. CSPRNG. IMO.

There is no real BC issue here, IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--94eb2c0641602a7bf20547457653--