Re: /dev/random on Linux

[Pavel Machek <pavel@suse.cz>]

Hi!

> >>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?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/