Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98021
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.115 as permitted sender)
To: "Yasuo Ohgaki" <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>,
 "Lauri =?utf-8?q?Kentt=C3=A4?=" <lauri.kentta@gmail.com>,
 Leigh <leight@gmail.com>, "Nikita Popov" <nikita.ppv@gmail.com>
Date: Sun, 29 Jan 2017 11:22:46 -0500
Message-ID: <0D26A03B-6BEB-4730-8E4B-0F7D6835E683@thefsb.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="=_MailMate_13FF8D36-0427-46EF-98D9-E49DB1B9906E_="
Subject: Re: [PHP-DEV] Re: Improving mt_rand() seed
From: fsb@thefsb.org ("Tom Worster")

--=_MailMate_13FF8D36-0427-46EF-98D9-E49DB1B9906E_=
Content-Type: text/plain; format=flowed; markup=markdown
Content-Transfer-Encoding: quoted-printable

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-re=
cord-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.


> 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.


> 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.


>  - 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.

Tom

--=_MailMate_13FF8D36-0427-46EF-98D9-E49DB1B9906E_=--