Am Freitag, 22. April 2016, 16:49:54 schrieb Sven M. Hallberg: Hi Sven,
> > 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? May I ask you to direct your attention to section 1.1. The legacy /dev/random has three noise sources: block devices, HID and interrupts. With those noise sources, only the block device and HID noise sources are interpreted to collect entropy between zero to 11 bits per event. The interrupt noise source is credited one bit of entropy per 64 received interrupts (or the expiry of 1 second, whatever comes later). With that, the legacy /dev/random values block device and HID events with much higher entropy than interrupts. And that is warranted given that there is a high correlation between block devices / HID and interrupts. Thus, it is not possible to value the interrupt events with higher entropy. During boot, there are no HID events. If the system has an SSD, the kernel will mark this block device to not be used for block device entropy collection as the legacy /dev/random block device noise source rests on the pick up of spinning disk turbulence and spin angle wait times. This all is simply not present with SSDs. This implies that during boot with SSDs, you only have the interrupt noise source which values an interrupt with at most 1/64th bit of entropy. The same applies to Device Mapper setups or the use of VirtIO block devices. My measurements show that even in worst case scenarios, interrupt timings using a high resolution timer have 11 and more bits of entropy. To be on the save side, I interpret each interrupt to have about 0.9 bits of entropy. And I do not specifically look for block device and HID events which does not introduce the correlation problem the legacy /dev/random noise sources have. As during boot, hundreds of interrupts are generated, and I have the valuation of about 0.9 bits of entropy per interrupt event, the LRNG will collect entropy much faster. > > I'm also having trouble telling at a glance the exact blocking behavior > of the interfaces proposed. It seems that /dev/random and getrandom() > will block when the estimated entropy in the "seed buffer" is below some > threshold. But numbers mentioned are 32, 112, and 256; which is it and > when? About /dev/urandom it says that reseeds are required periodically. > Are these subject to blocking? /dev/random gets its data from the primary DRBG. The primary DRBG is designed to only release as many bytes as it was seeded with entropy. Thus, if you noise sources can only deliver, say, 16 bytes of entropy, a read request will receive those 16 bytes. Then, the caller is blocked. If new entropy comes in, the caller is woken up when reaching the wakeup threshold. This has the same logic as the legacy /dev/random. getrandom(NONBLOCK) will block until the secondary DRBG is fully seeded during initialization (i.e. 256 bits when using the suggested DRBG types which have 256 bits of security strength). Afterwards, it operates like /dev/urandom. This has the same logic as getrandom has with the legacy /dev/random implementation where the getrandom call blocks until the nonblocking_pool is seeded (with 128 bits). I.e. getrandom(NONBLOCK) unblocks when /proc/sys/kernel/random/drbg_fully_seeded turns to one (or the dmesg shows the entry about the DRBG being fully seeded). /dev/urandom will not block as it is the case with the legacy /dev/urandom. Ciao Stephan _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
