Hi Stas, Thank you for sharing opinion. Followings is mine.
On Tue, Jul 5, 2016 at 7:23 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: >> Could you share the reason why against this change? > > 1. I'm not sure exporting raw generator state is a good practice. I may > change my opinion on the subject if I hear from some security people > (I'm no crypto expert) that this is ok, then I may change my opinion. I think no one can guarantee security of CSPRNG on all platforms. "CS" means cryptographic safety and cryptographers recommends not to reinvent crypt related functions/features. > 2. Due to (1), I do not think it makes sense to do this change, because > we produce no benefit (session generation speed is not that important > since nobody generates millions of sessions at once) and create > potential problems. Current implementation is regenerating random hash string by using - PID - Time (Simple random function) - CSPRNG when it is available 10 years ago, I would agree with your opinion, since old PRNG is not as good as current one. Today, I don't see the reason why we should reinvent secure random bytes as we do now. I agree we should have some mitigations just in case a CSPRNG is broken badly. The patch uses 4 to 6 bits to generate readable string and read extra 60 bytes to hide raw PRNG state. This mitigation should be good enough for somewhat broken CSPRNG. In addition, even when CSPRNG generates the same random bytes, session module has collision detection and will not create the same session ID. I hope you and others are convinced by this explanation. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
