On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller <smueller@xxxxxxxxxx> wrote: > Hi Herbert, Ted, > > The venerable Linux /dev/random served users of cryptographic mechanisms well > for a long time. Its behavior is well understood to deliver entropic data. In > the last years, however, the Linux /dev/random showed signs of age where it has > challenges to cope with modern computing environments ranging from tiny embedded > systems, over new hardware resources such as SSDs, up to massive parallel > systems as well as virtualized environments. > > With the experience gained during numerous studies of /dev/random, entropy > assessments of different noise source designs and assessing entropy behavior in > virtual machines and other special environments, I felt to do something about > it. > 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. A secondary design > goal is to limit the impact of the entropy collection on massive parallel > systems and also allow the use accelerated cryptographic primitives. Also, all > steps of the entropic data processing are testable. Finally massive performance > improvements are visible at /dev/urandom / get_random_bytes. [quote from pdf] > ... DRBG is “minimally” seeded with 112^6 bits of entropy. > This is commonly achieved even before user space is initiated. Unfortunately one of the issues of the /dev/urandom interface is the fact that it may start providing random numbers even before the seeding is complete. From the above quote, I understand that this issue is not addressed by the new interface. That's a serious limitation (of the current and inherited by the new implementation), since most/all newly deployed systems from "cloud" images generate keys using /dev/urandom (for sshd for example) on boot, and it is unknown to these applications whether they operate with uninitialized seed. While one could argue for using /dev/random, the unpredictability of the delay it incurs is prohibitive for any practical use. Thus I'd expect any new interface to provide a better /dev/urandom, by ensuring that the kernel seed buffer is fully seeded prior to switching to userspace. About the rest of the design, I think it is quite clean. I think the DRBG choice is quite natural given the NIST recommendations, but have you considered using a stream cipher instead like chacha20 which in most of cases it would outperform the DRBG based on AES? regards, Nikos -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
