> 2010/12/21 Theo de Raadt <dera...@cvs.openbsd.org>: > > HANG ON. > > > > Go look at the function random_seed() in /usr/src/etc/rc > > Then look at when it is called. > > so, the current state of the PRNG will be preserved during reboots.
That statement is false. > Good. No. You misread the code. > That gives some information about system entropy, which will be > "good" at all times, except for the very first boot of an > installation. See : rnd.c: randomwrite() -> add_entropy_words(); That part is true. But what you said earlier is false. > However, arc4_stir will still be called once after every reboot. > During its first call, the value of nanotime() will be placed at the > beginning of buf, which is then beeing used to init the rc4 context. What else do you think we should use? Where do we invent entropy from when the kernel has only been running for 0.01 of a second? > So, at the first glance it looks like using the value of nanotime() in > arc4_stir is not necessary at all, as there will allways be enough > system entropy. False. On some architectures, some entropy might have been fetched. On some architectures, the system clock might have been read with enough accuracy and random time advancement to provide some unknown. On MOST architectures, the above two are true. On some they are not. Soon after mounting, /etc/rc will load a bucketload more entropy (even on the first boot, I should add, since even the installation process generates that file). > At least I would XOR the value of nanotime() to buf, > instead of just prepending it. MD5 and the like does not seem to be > necessary, as buf will allways contain some good random data. XOR it? Why? Please provide a citation regarding the benefit of XOR'ing feed data before passing it into MD5 for the purpose of PRNG folding. Note, this is the first stage PRNG, and that a second stage kernel-use PRNG is built on top of that the first one, and that a third stage per-process PRNG is built on top of that.
