[Cryptography] Entropy Needed for SSH Keys?

[Natanael]

Den 24 maj 2016 7:15 em skrev "Jerry Leichter" <leichter at lrw.com>:
>
>
> >> But, honestly, I sincerely question the idea that you need random
> >> numbers "early" in the boot process.
> >
> > The caveat here is kernel ASLR.  The address space is setup when the
> > decompressor is run.  It either needs an architecture-specific function
> > like RDRAND/RDSEED, or to be handed a seed by the bootloader.
> >
> > There's also the whole suite of kernel self-protection mechanisms like
> > stack canaries and so on.
> Let's think this through a bit.  Kernel ASLR, stack canaries, and so on,
are there to protect against external code that finds holes.  Early during
boot, *there's no external code running*.  We're before network
initialization, so there's nothing coming in from the network links.
Basically, if an attacker has managed to get code running at this point
during boot, you don't have much hope anyway.
>
> So it seems to me you want to address a different issue:  Not how do I
get enough randomness to set up kernel ASLR and related mechanisms early in
boot, but how to I *put off* setting up kernel ASLR and related mechanisms
until I have a usable source of randomness?

Let the bootloader / UEFI do it?

If the question is how to load and run code complex enough to interact with
potentially arbitary hardware to fetch meaningful entropy, before the
kernel has had a chance to prepare anything, without making the boot
process more complex, it seems like that's the only clear answer.

The bootloader has to already know a thing or two anyway about the hardware
and get a few things up and running, and letting it pass on entropy to the
kernel as it loads it to memory keeps the overhead low.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160524/21d19eae/attachment.html>