Am Donnerstag, 21. April 2016, 15:03:37 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > 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. That limitation is addressed with the getrandom system call. This call will block until the initial seeding is provided. After the initial seeding, getrandom behaves like /dev/urandom. This behavior is implemented alredy with the legacy /dev/random and is preserved with the LRNG. > > 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? This can easily be covered by changing the DRBG implementation -- the current DRBG implementation in the kernel crypto API is implemented to operate like a "block chaining mode" on top of the raw cipher. Thus, such change can be easily rolled in. Ciao Stephan -- 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
