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.

[ message continues ]

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 ...
[ message continues ]

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

[ message continues ]

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)?

[ message continues ]

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.

[ message continues ]

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

[ message continues ]

because it is accessible *before* any filesystem is mounted, from second 
0 of the boot process.

- Salva

[ message continues ]

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?

[ message continues ]

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...

[ message continues ]

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

[ message continues ]

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

[ message continues ]

If you can only read.........

[ message continues ]