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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
