Hi Tom, On Mon, Jan 30, 2017 at 1:22 AM, Tom Worster <f...@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 yohg...@ohgaki.net
