On 09-Mar-15 07:29, Tony Finch wrote: > Robert Martin-Legene <rob...@pch.net> wrote: >> Does anyone have experiences using haveged for PRNG? When generating >> DNSSEC keys on a virtual server is takes a looong time to get >> randomness. > My view is that haveged might be snake-oil, but it is a useful way of > fixing braindamage in the Linux implementation of /dev/random. > > An RNG should block until it has been securely seeded, and after that it > should run freely. Linux /dev/urandom fails to block and /dev/random fails > to run freely. Sigh. Haveged at least fixes the /dev/random bogus entropy > estimation, but you should also check that your distro ensures the RNG is > properly initialized e.g. using a random seed file. > > http://www.metzdowd.com/pipermail/cryptography/2014-February/019920.html > http://www.mail-archive.com/cryptography@randombit.net/msg04763.html > http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ > http://www.2uo.de/myths-about-urandom/ > https://pthree.org/2014/07/21/the-linux-random-number-generator/ > > Tony. Without getting too far into the philosophical argument, a practical note:
Since I switched to a (securely distributed) hardware-based entropy source, blocking hasn't been a problem. My cheap USB device generates entropy faster than it's practical to consume it. Well, if you have local access to /dev/random, you can draw the pool down with dd. But then you have other issues... What I mean is that running a normal load, /dev/random doesn't block. And the entropy sources in CPUs are several orders of magnitude faster. If you're happy with /dev/urandom, but worry about failure to initialize the pool, there is a simple solution. Read one bye from /dev/random, which will block until the pool is seeded. After that call returns, use /dev/urandom... Or if you have a hardware device, you're OK once it starts feeding the pool. Modulo the 'malicious entropy source' argument. Again, if someone managed to connect such a device to your machine, you have other big issues. And, as I noted, a tool to detect faults that doesn't require a math degree to interpret would be a good thing. Until someone corrupts the tool. When you stop worrying depends on your threat evaluation. But that's the philosophical argument. haveged has the issues that I noted previously when a machine is idle. The above work-around may make haveged a rather large hammer for a pretty small nail. You should reconsider its use when dealing with idle (a.k.a secure) machines, and when your machine acquires a CPU with an entropy source. YMMV. -- This communication may not represent my employer's views, if any, on the matters discussed.
