[Pkg-sysvinit-devel] Re: /etc/init.d/urandom Suggestion

[Henrique de Moraes Holschuh]

On Sun, 26 Feb 2006, Kent Borg wrote:
> In general, Linux handles its entropy well, but there are some
> worrisome cases.  One example is the machine that is coming up fresh

Worrisome cases like the _entire_ 2.4 kernel tree?  No, Linux doesn't
generally handle its entropy well at all IMHO.  But 2.4 doesn't matter for
Debian Etch, so we can ignore it (and even if it did matter, bothering with
entropy accounting in 2.4 ain't useful in practice).

> from an install and maybe generating its first keys.  Another example
> is a machine that has crashed and will be booting with an entropy file
> that has essentially been used before.
> 
> My suggestion is to add one line, something vaguely like:
> 
>   cat /dev/mem > /dev/urandom

Well, IMHO instead of doing that, we should just don't touch urandom.  Which
means we make triple sure *no* urandom initialization data ever gets used
twice, but that's about it  (I didn't check if the code we have right now is
paranoid enough, though.  If it isn't, we would do well to fix that).

Let me explain: the latest (all?) 2.6 versions of the Linux kernel know how
to deal with an initially "empty" entropy pool (or at least how to
*consistently* deal with it as compared to what it will do as the system
runs).

The entropy pool *will* take time to fill up, of course, but unlike
/dev/mem, where you have to make a lot of assumptions (which *can* be wrong,
e.g., on hypervisor-based virtual machines, weird embedded hardware, etc),
it will do so from safer heuristics (because it basically does what the
kernel will be doing the rest of the time the system is up, anyway).

The initial pool state is *not* necessarily deterministic, the kernel does
not zero the entropy pool upon /dev/random startup, as it once did (the
platform might, though).  It uses whatever noise is there, but it counts
that as *zero* entropy added to the pool, which is safe even if something
always set that memory to the same state before bootstrapping the kernel.

If you need *seriously* random numbers, or a big number of them, you'll need
a TRNG, the Linux kernel won't be enough.  Get yourself a VIA Nehemiah (or
newer) CPU with a Padlock engine with dual TRNG cores, and Debian rng-tools
(in experimental, not the one in Sid) will give you several Mbit/s
(sustained!) of true random data.

> Current RAM technology is volatile.  Its power-on state is subject to

As far as I understood your idea, your assumptions are based on a premisse
that is not known to be true on all platforms running Debian: that you are
using DRAM, and that nothing is pre-filling it with known values.

Please correct me if I am wrong, but also point out why we should not stay
on the completely safe path of letting the kernel do the initial seeding.

> significant patterning, but it is not completely predictable.  A new

It is pretty predictable in platforms that initialize memory during boot (to
initialize ECC, to detect memory errors and holes, or just because they want
to).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh