Re: /dev/random on Linux

From: Pavel Machek
Date: Tue May 16 2006 - 09:14:54 EST


> >>I would dismiss 2.2 for the cases of things like Knoppix because
> >>CDs introduce significant randomness because each time you boot
> >>the CD is subtly differently positioned. The OpenWRT case seems
> >>more credible. The hard disk patching one is basically irrelevant,
> >>at that point you already own the box and its game over since you
> >>can just do a virtualization attack or patch the OS to record
> >>anything you want.
> Any system with a cycle counter has a vast amount of entropy
> available by the time the system even gets through the BIOS. Various
> things like memory timing, power initialization, BIOS tests, etc are
> all sufficiently variable in terms of CPU clock cycles that the value
> of the cycle counter at the first bootloader instruction executed has
> several bits of randomness. By the time the bootloader has
> optionally waited for user input and loaded the kernel off the disk,
> chaotic variability in the disk access for HDDs, CDROMs, etc will
> make many bits of the cycle counter sufficiently random. At that
> point there's a decently random seed, especially once you start
> getting further-randomized cycle-counter-based disk interrupts. I
> believe there was a paper that discussed how air turbulence in a disk
> drive was sufficient on a several hundered MHz CPU to provide lots of
> entropy per interrupt from the cycle counter alone.
> This is totally untrue for an embedded flash-based system; but for
> such a system the only way to get any kind of entropy at all is with
> a hardware RNG anyways, so I don't really see this as being a problem.
> I was unsure about the purported forward-security-breakage claims
> because I don't know how to validate those, but I seem to recall
> (from personal knowledge and the paper) that the kernel does an SHA1
> hash of the contents of the pool and the current cycle-counter when
> reading, uses that as input for the next pool state and returns it
> as /dev/random output. Since the exact cycle-counter value is never
> exposed outside the kernel and only a small window of the previous

Are you sure? For vsyscalls to work, rdtsc has to be available from
userspace, no?
(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at