Re: Re: [RFC][VOTE] Session ID without hashing

Hi Dan, On Fri, Jul 8, 2016 at 5:33 AM, Dan Ackroyd <danack@basereality.com> wrote: >> 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. I understand concern and I would not argue against that hashing should still obfuscate PRNG state. The patch proposed/session module has mitigations - Read extra bytes from RPNG to hide raw PRNG state (This should be good enough mitigation for usable CSPRNG) - In case PRNG generates the same session IDs repeatedly, it terminate execution with E_ERROR/E_RECOVERABLE_ERROR. (This shouldn't happen with good CSPRNG) Above mitigations should be good enough for CSRPNG applications. System with seriously broken CSPRNG should not be used anyway. IMO. Vote requires 2/3 in favor. Current vote is 6 vs 3. If this RFC declined, I'll prepare patch that has optional hashing. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net