Stephan Müller <smueller@xxxxxxxxxx> wrote: > In an effort to provide a flexible implementation for a random number > generator that also ... As usual, some of your proposals make considerable sense to me & others do not, at least on first reading. I may have more comments after reflecting some. Meanwhile, a couple of things jump out at me: > (a) When an interrupt occurs, the high-resolution time stamp is mixed > into the LFSR. ... > > (b) HID event data like the key stroke or the mouse coordinates are > mixed into the LFSR. ... > > (c) Device drivers may provide data that is mixed into the LFSR. ... Why into the LFSR instead of into the entropy pool? > The LRNG allows the TRNG and secondary DRNG mechanism to be changed > at runtime. Why? This strikes me as pointless complication. > * high performance of interrupt handling code: The LRNG impact on the > interrupt handling has been reduced to a minimum. On one example > system, the LRNG interrupt handling code executes within an average > of 65 cycles whereas the existing /dev/random on the same device > takes about 97 cycles when measuring the execution time of > add_interrupt_randomness(). Assuming you do this without sacrificing the input mixing, this would be worth submitting as a separate patch. Saving cycles on every interrupt definitely looks worth doing. > * lockless LFSR to collect raw entropy This too.
