anonym: > 26/11/12 16:40, Jacob Appelbaum wrote: >> intrigeri: >>> Hi, >>> >>> we're asked to install ekeyd to support EntropyKey: >>> https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/ >>> >>> The total installed size of the needed packages is a few hundred >>> kilobytes. I think it's worth adding to improve cryptography -related >>> hardware support. What do you think? > > Given what I've read about HAVEGE (or rather, mostly the lack of good > criticism) it seems like we already have solved the problem of > generating good random numbers at will in Tails by installing haveged. > I'm not against the inclusion of ekeyd, however.
Seems reasonable. I don't know that I'd call it solved because it is extremely hard to know if the random numbers are, well, actually entropic. :-/ > >>> Cheers, >>> >> >> I think it is a good idea. I regularly install it with Tails anyway. >> >> It might also make sense to include rng-tools, randomsound, and haveged >> for around of 1,098 kB on disk. > > Tails do install haveged by default. > I missed that haveged is installed. Glad to hear it. >> Tails should really do everything >> possible to collect entropy as often as possible; if the rng runs dry, >> all the crypto fails badly... It might even be worth seeding the rng >> from an unlocked persistence partition - it should be possible to drain >> /dev/random of ~200 bits of entropy at any given point in time to ensure >> that the rng never goes unseeded... > > Running (in Tails): > > cat /dev/random | pv > /dev/null > > reports a pretty stable rate of 2MB/s on my system, which should be > sufficient for all *realistic* use cases. Given that the rate is good I > don't see any reason for mixing in additional entropy sources, like you > propose, except if haveged doesn't have good enough entropy quality on > its own. > I admit, I find a high performance RNG to be... less than compelling. > Here's two pretty interesting blog posts about haveged and its entropy > quality: > > http://jakob.engbloms.se/archives/1370 > http://jakob.engbloms.se/archives/1374 > I generally agree with the author - our tests about the entropic nature of a bitstream are pretty weak. It seems to me that (at debian-install time) the system will likely have very little variation. At boottime on a given piece of hardware, I imagine this is also true for repeated runs if one could reset the hardware to the "original" state. The goal for me isn't perfect predictability but rather, predictability within a certain set of bounds. I think that is related to the point of the Proartis[0] project. > Most points raised in them seem highly academic, though, so my > conclusion is that haveged is good enough on its own. > I think that almost no single entropy source is good alone. The kernel should take a few and mix them together, hopefully the kernel's mixing works well enough. I remember hearing that the entropy pooling system was going to get an overhaul after Nadia's paper, I wonder if that happened? I think it would be interesting to know how the rdrand CPU flag is utilized in Tails? If a machine has it, will the kernel automatically use this entropy source? It would also be interesting to see if randomsound would at least make the attack surface of the microphone worthwhile... All the best, Jake [0] http://www.proartis-project.eu/ _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev