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