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/
