> > > I think we need to drop the concerns about exposing "RNG state". > > > > If these are weak RNGs on your system, YOUR SYSTEM is broken. > > Telling people that their system is broken isn't going to be > comforting to the people it happens to. >
Sure, but it's the right way. Just like random_bytes having no fallback. There are always bugs in software and hardware. At some point it is > almost inevitable that there will be some information leak through > exposing the random numbers directly. Just telling people that their > system is broken and they need to buy need hardware immediately, > rather than just being able to re-enable hashing seems a bad choice. > Nobody talks about buying new hardware. It usually happens due to bad system setup, such as blocking access to /dev/random. But even without accidental bugs, the scenario I am remain concerned > with is when a piece of hardware or software is compromised by a > sophisticated attacker, (hello NSA!) and the 'random' numbers > generated have some subtle pattern to them. To almost everyone, the > random numbers generated would still look random. But to the > organisation that compromised the system, and so knows the algorithm > that is leaving traces in the random sequences, exposing the random > numbers directly to the outside world would be an obvious but almost > untraceable line of attack on the system. > > Hashing should still obfuscate any subtle patterns in the random > number generation, and so give some protection against comprised > chip-set/firmware. If users choose to continue to want the extra > security of hashing, at the cost of slightly slower session ID > generation we shouldn't removed that from them. > > Yasuo wrote: > > Some of us worried about CSPRNG state exposure. I'm wondering how many > > of you will vote in favor if I change the RFC to use hash functions > > optionally. > > Yes. > > Though as I said before, I think changing session.use_strict_mode > should be a separate decision, and it's one I support doing. > > cheers > Dan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
