Re: Re: Improving mt_rand() seed <lauri.kentta@gmail.com>
| From: | Yasuo Ohgaki | Date: | Sat, 28 Jan 2017 21:32:34 +0000 |
| Subject: | Re: Re: Improving mt_rand() seed <lauri.kentta@gmail.com> | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-98013@lists.php.net to get a copy of this message | ||
Hi Tom,
On Sun, Jan 22, 2017 at 1:26 AM, Tom Worster <fsb@thefb.org> wrote:
> On 1/20/17 9:55 PM, Yasuo Ohgaki wrote:
>
>> CSPRNG failure is like BUS error, i.e. hardware error. CSPRNG shouldn't
>> fail with healthy hardware/OS.
>>
>
> One would like to think so but low entropy environments exist. The problem
> may even be getting more widespread as embedded systems become more
> widespread.
>
Could you give some examples?
I'm not sure what kind of IoT devices/OS that support PHP do not have
CSPRNG.
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.
> Therefore, we should not add poor fallback
>> code for it.
>>
>
> I don't see a need or value in breaking programs that previously worked
> properly in the absence of a functioning system CSPRNG.
>
> mt_rand() and uniqid() were not secure before so seed them securely if you
> can otherwise let them work as they did before.
>
Issues are
- Current mt_rand() is not fully exploited. It wastes more than 99% of its
random cycle.
- Current uniqid()'s entropy is extremely poor and there is fair chances
for collisions.
Question is
- Are we going to keep these poor behaviors as PHP spec/standard forever
or not.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net