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.
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
