2010/12/22 Theo de Raadt <dera...@cvs.openbsd.org>: >> so, the current state of the PRNG will be preserved during reboots. > > That statement is false.
you're right. As you posted in the other thread, the output of the PRNG is saved during shutdown and that file is loaded as entropy data during startup. > No. You misread the code. I understood the code, just my description of the process was not correct (detailed enough). >> 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? I don't know. I just wanted to discuss a possible "issue". That's all... > Where do we invent entropy from when the kernel has only > been running for 0.01 of a second? O.K. where do you need ramdom bytes during that state of the kernel? All locations where arc4random* is called in the kernel are these: src/sys/dev/ic/if_wi.c: sc->wi_icv = arc4random(); src/sys/dev/ic/if_wi_hostap.c: arc4random(); src/sys/dev/ic/rt2860.c: uint32_t val = arc4random(); src/sys/dev/softraid_crypto.c: arc4random_buf(sd->mds.mdd_crypto.scr_key, src/sys/dev/softraid_crypto.c: arc4random_buf(sd->mds.mdd_crypto.scr_maskkey, src/sys/dev/usb/if_uath.c: iv = (ic->ic_iv != 0) ? ic->ic_iv : arc4random(); src/sys/dev/usb/ehci.c: /* XXX prevent panics at boot by not using arc4random */ src/sys/dev/usb/ehci.c: islot = EHCI_IQHIDX(lev, arc4random()); src/sys/dev/pci/ubsec.c: arc4random_buf(ses->ses_iv, sizeof(ses->ses_iv)); src/sys/dev/pci/safe.c: arc4random_buf(ses->ses_iv, sizeof(ses->ses_iv)); src/sys/dev/pci/noct.c: arc4random_buf(iv, sizeof(iv)); src/sys/dev/pci/if_iwi.c: arc4random_buf(&data, sizeof data); src/sys/dev/pci/if_ix.c: arc4random_buf(&random, sizeof(random)); src/sys/dev/pci/hifn7751.c: arc4random_buf(ses->hs_iv, src/sys/dev/softraid.c: arc4random_buf(uuid->sui_id, sizeof(uuid->sui_id)); Those in dev/pci are about initializing hardware encryption devices. The rest of the calls (to the level I checked), will need at least the root filesystem to load some config data and then init some stuff (i.e. WEP key generation, etc.). So, until the filesystem is mounted, there is no need for arc4random() in the kernel. After the filesystem has been mounted the entropy data will be loaded from the file. If this is true. Where is the need for the time value in arc4_stir()?? Maybe I'm wrong. If so, please direct me to the code that needs arc4random() before the filesystem has been mounted, maybe EXCEPT the hardware crypto devices. Most certainly those drivers don't need arc4random during kernel init as well. >> So, at the first glance it looks like using the value of nanotime() in >> 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? To fold the plain time value into some other random data returned by get_random_bytes. If it's a bad idea to "stir" or "fold" data that way, why is MD5 used in extract_entropy() to achieve the same goal? > Please provide a citation regarding the benefit of XOR'ing feed data > before passing it into MD5 for the purpose of PRNG folding. I did not say that. I said, that XORing the time value with the data of get_random_bytes() is probably sufficient and that MD5 would not be required.
