On Fri, Apr 22, 2016 at 04:49:54PM +0200, Sven M. Hallberg wrote: > > I developed a different approach, which I call Linux Random Number Generator > > (LRNG) to collect entropy within the Linux kernel. The main improvements > > compared to the legacy /dev/random is to provide sufficient entropy during > > boot > > time as well as in virtual environments and when using SSDs. > > After reading the paper, it is not clear to me how this goal is > achieved. As far as I can see, no new sources of entropy are > introduced; in fact a point is made to use only interrupt timings, > arguing that these effectively include other events. Why does this > design make more entropy available during boot and with solid-state > storage?
Indeed. I think it would be desirable to clearly separate work to reorganize and modernize the core entropy-gathering and DRBG constructions (which closely parallels work Taylor Campbell and I did in NetBSD) from work to ingest more unpredictable data at boot time (which I also subsequently did in NetBSD). On the former score (improvement and modernization of the mechanism) I think in NetBSD we still have quite a bit of room for improvement. On the latter, I think we do about as well as anyone. A key insight for me came from Peter Gutmann: it is important to ingest data you have strong reason to believe are truly random; but it is also important to ingest data you have strong reason to believe are merely expensive and difficult for a prospective adversary to measure or predict. In the real world, the latter can often save your butt, or your customers' butts. So we eat things like the first several seconds of frames from the network; dmesg output; TOD; IP addresses; hostnames; and other configuration and nonsecret data that will vary from system to system and which an adversary would have to measure in the field rather than predicting _a priori_; as well as data like temperature, voltage, and fan speed which we know to be related to one another, but through (to again paraphrase Peter) physical processes which are very difficult to model; _plus_ the timestamps and other "TRNG" data that are the traditional food of system entropy pools. And we never, ever feed output based solely on input from a single source. If you trust your pool and output stream constructions, this approach can clearly be no worse than relying solely on timings; and in practice, I believe it is far more expensive for an adversary to attack. Thor _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
