Tails

#4 Updated by BitingBird 2015-01-08 03:59:20

geb, do you still plan to audit that ? If yes, that’s great - if not, please remove yourself from assignee :)

#6 Updated by intrigeri 2015-02-10 15:34:59

David Goulet wrote on Feature #5650#note-16:

> There is a fallback usually to rdtsc. In haveged case, the generic fallback is:
>
> clock_gettime(CLOCK_MONOTONIC, &ts);
>
> The monotonic clock is used. It can NOT go back in time but might subject to incremental adjustement by any NTP correction. Still much better than using “date +%s”.

#13 Updated by cypherpunks 2016-03-02 02:58:46

One solution would be to have haveged XOR its contents with the pool without issuing the ioctls to raise the pool’s entropy estimate. This can be done by writing constantly to the pool through the randomness device, such as by running the following in the background at start up:

haveged -n 0 -f - 2>/dev/null | pv -q -L 1024 >/dev/urandom

This will write to /dev/urandom at a rate of 1024 bytes per second (I think it actually writes it in bursts of 4096 or 512 bytes but I really don’t remember and I don’t have strace on hand right now). The overhead is extremely small even on very low-power netbooks, and should provide far superior randomness to using regular haveged, while additionally not increasing the entropy estimate by itself.

An alternative would be to write to /dev/urandom in chunks every 10 minutes or so, by adding something like this to a cron job:

haveged -n 1M -f /dev/urandom 2>/dev/null

That won’t provide the same recovery speed against PRNG state compromises, but it will skip the admittedly low overhead of pv.

I would personally recommend using the former. I’ve used something akin to that for many years. The only downsides I can see for either of these options is with Pidgin’s OTR key generation, which by default reads from /dev/urandom, and generating GPG keys, which do the same.

#14 Updated by cypherpunks 2017-01-15 03:34:34

intrigeri wrote:
> David Goulet wrote on Feature #5650#note-16:
>
> > There is a fallback usually to rdtsc. In haveged case, the generic fallback is:
> >
> > clock_gettime(CLOCK_MONOTONIC, &ts);
> >
> > The monotonic clock is used. It can NOT go back in time but might subject to incremental adjustement by any NTP correction. Still much better than using “date +%s”.

That is only a fallback if TSC support is reported missing by the CPU. In some hypervisors, it doesn’t report it missing, instead it traps it and returns NULL in eax and edx. This means haveged falsely thinks it has a working TSC.

I don’t think Tails will ever be in a situation where the clock_gettime() fallback is used, because no hypervisor should report a CPU with a missing TSC, and Tails does not support any CPU architectures that genuinely lack a TSC (modern x86 and ARM support it). The only problems that can occur, as far as I know, are Tails being provided with a bogus TSC.

I don’t know if this is a problem for the kernel’s entropy generator, since it calculates the deltas between three RDTSC invocations before incrementing the entropy estimate in add_timer_entropy(). Someone should test this in bochs.

#17 Updated by dkg 2018-04-11 18:02:39

Can i zoom out a bit and ask why specifically you’re thinking about haveged? Concretely, what task do you need it for? What underlying systems use blocking /dev/random ? when during the life cycle of the vm do they use it?

one thing i can think of is GnuPG secret key generation. I think that’s a bug in GnuPG and should be worked around there. (see https://dev.gnupg.org/T3894). Are there other use cases driving the need for haveged?

#20 Updated by sycamoreone 2018-10-02 11:01:22

dkg wrote:
> Can i zoom out a bit and ask why specifically you’re thinking about haveged? Concretely, what task do you need it for? What underlying systems use blocking /dev/random ? when during the life cycle of the vm do they use it?

One program/library that uses /dev/random is pidgin-otr/libotr. Without a system such as haveged pidgin will freeze during key generation without any notification about what is happening: https://bugs.otr.im/plugins/pidgin-otr/issues/63#note_412

#22 Updated by intrigeri 2019-10-03 04:35:51

Linux 5.4 will likely include a “jitter entropy” mechanism, similar in essence to what haveged is doing (detailed source will become public in a few days). So it might be that at some point we can simply drop haveged and close this ticket :)

Also, quoting from that article:

> Matthew Garrett pointed out that the Zircon kernel for the Fuchsia operating system initializes its CRNG using jitter entropy, which may lend some credibility to the technique.