On Wednesday, July 25, 2018 9:14:40 AM CEST Sander van Grieken wrote: > I did some digging, as I was a bit surprised QHash needs (secure) randomness > at all. > > Turns out, reading http://doc.qt.io/qt-5/qhash.html#qhash , that QHash has > an inbuilt protection against hashtable bucket bias attacks (chosen input > that hashes into the same hash value, and therefore into the same hashtable > bucket, leading to performance hits). > > Not sure where sddm uses the QHash, but it seems unlikely to me that there > is much potential for large amount of user controlled data ending up in the > QHash. > > In that case, sddm could just initialize the random seed by using > qSetGlobalHashSeed() with zero or some pseudo-random value and avoid the > wait for entropy.
I'm no expert, but what you say seems reasonable. Also, introducing Haveged could lead to sensitive application using "questionable" entropy. <quote> HAVEGE is a random number generator that exploits the modifications of the internal CPU hardware states (caches, branch predictors, TLBs) as a source of uncertainty. During an initialization phase, the hardware clock cycle counter of the processor is used to gather part of this entropy: tens of thousands of unpredictable bits can be gathered per operating system call in average. https://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines </quote> That seems sound to me... But some security issues that have been found lately seem also so terribly remote.
