What else do you think we should use? Where do we invent entropy from 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 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.
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 I understood the code, just my description of the process was not 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 ...
Could a random seed be patched into the kernel image at installation time? Admittedly this is not entropy, this is a just secret key and anyone with access to the machine would be able to read it, but from the outside, specially considered that machines are not rebooted so often (and when they are, it is usually for updating them), it would look like real random data. - Salva
Now that it's amateur suggestion hour (no offense Salva), I'm going to take a shot. Would it be possible to use what randomness the system does have to seed some reader that pseudo-randomly reads arbitrary bits from the loaded kernel image in RAM? This may differ per system, but doesn't uninitialized RAM start in an "unknown state?" If so, could that be added to the entropy pool if it is determined to be random (i.e. not initialized to zeros)?
I think we'd much rather just have a good random generator, than rely on one of uncertain quality. If the system really, really, really needs random numbers before entropy is available, then we should fix that problem, not try to magic up some entropy.
Well whatever you might read will fall into three classes: 1 Bits that are fixed in the kernel image. Obviously these don't count 2 Bits that can go for long periods without changing. 3 Bits that change frequently. You might as well read these directly. The challenge with (3) and especially (2) is quantifying how much entropy you have actually gathered. If you can't quantify it, it doesn't help you turn on the system faster. This is the main reason why high speed timers are so valuable: you at least expect them to change on a regular basis. Of course, they're so regular that you have to use the uncertainty of some other event to query the timer. So the timer is just a way to convert timing uncertainty into bytes, it's not a source of entropy itself. If only the universe had more than one time dimension, more entropy could be gathered at each event. But many CPUs actually do have more than one and they can vary more or less independently. For example, on i386 and amd64 there's a 'readtsc' instruction. It has a very fast rate (e.g. CPU frequency) and it varies along with CPU frequency scaling. Even better, it's notoriously hard to get consistent results on multicore platforms. Unfortunately, I just read the Wikipedia article and they indicate that Intel CPUs are standardizing on giving it Sure. But it depends on all kinds of physical factors. How much did you get? Is it safe for the boot process to generate keys now? Answering those questions accurately is more important than gathering bonus entropy that you can't be sure of. - Marsh
because it is accessible *before* any filesystem is mounted, from second 0 of the boot process. - Salva
This reminds me of something. The last time I installed FreeBSD about 5 years ago, it asked me to pound on the keyboard for like 60 seconds during installation (or at first boot, can't remember) in order to build up some "randomness". I wonder what kind of entropy that provided?
It was only the first time sshd starts to generate enough entropy for the ssh-key generation. http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/sshd?rev=1.14;content-type=text%2Fp...
In our case, the aim is to use the entropy collected during install by the various entropy sources (tty, disk io, network io and more) to generate a random seed that's being saved to disk so the first real boot is able to stir the random pool with that and have enough entropy to generate good hostkeys. -Otto
run it through a hash function and it's a good value. Patch that value into the kernel and it's available from the start of the kernel. Then use that value as a key for a HMAC, to hash time values (and other entropy). Do all that and you have a good seed for a PRNG. Unpredictable, different every time, different on all systems. Regards Kurt Knochner http://knochner.com
If you can only read.........
|Jesse Barnes||Re: [stable] [BUG][PATCH] cpqphp: fix kernel NULL pointer dereference|
|Greg KH||[003/136] p54usb: add Zcomax XG-705A usbid|
|Magnus Damm||[PATCH 03/07] ARM: Use shared GIC entry macros on Realview|
|Oliver Neukum||Re: [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30|
|Martin Schwidefsky||Re: [PATCH] optimized ktime_get[_ts] for GENERIC_TIME=y|
|Junio C Hamano||Re: Some advanced index playing|
|Jeff King||Re: confusion over the new branch and merge config|
|Robin Rosenberg||Re: cvs2svn conversion directly to git ready for experimentation|
|Linus Torvalds||git binary size...|
|Ævar Arnfjörð Bjarmason||Re: Challenge with Git-Bash|
|Linux Kernel Mailing List||md: move allocation of ->queue from mddev_find to md_probe|
|Linux Kernel Mailing List||md: raid0: Represent zone->zone_offset in sectors.|
|Linux Kernel Mailing List||[ARM] S3C24XX: Add gpio_to_irq() facility|
|Linux Kernel Mailing List||md: raid0_make_request(): Replace local variable block by sector.|
|Linux Kernel Mailing List||md: Allow md devices to be created by name.|
|kaber||[PATCH 07/12] netfilter: xtables: change hotdrop pointer to direct modification|
|Gerrit Renker||[PATCH 3/5] dccp ccid-2: Remove redundant sanity tests|
|David Miller||Re: [PATCH net-next-2.6] pcnet32: Remove redundant set of skb->dev|
|Gerrit Renker||[PATCH 4/5] dccp ccid-2: Simplify dec_pipe and rearming of RTO timer|
|Saikiran Madugula||[PATCH] Allow fragmentation of VLAN packets traversing a bridge.|
|Ryan Stone||Re: Re: [Call For Testing] VirtualBox for FreeBSD! take2|
|Alexey Shuvaev||Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)|
|Cristian KLEIN||Re: small purposal for change in installworld|
|FreeBSD Tinderbox||[head tinderbox] failure on sparc64/sparc64|
|Mark Martinec||Support for newer Ethernet chips in RE(4) driver?|