[Cryptography] /dev/random is not robust

[Nico Williams]

On Tue, Nov 05, 2013 at 12:12:32AM +0400, Yuriy Kaminskiy wrote:
> It is not only *installer* issue, it also affects popular "ephemeral swap" (or
> "ephemeral temporary fs") setup,
> 
> === /etc/crypttab ===
> cryptoswap	/dev/[...]	/dev/urandom	swap
> === /etc/fstab ===
> /dev/mapper/cryptoswap	none	swap	sw	0	0
> === end ===
> 
> [...]
> 
> Oh, and init.d/urandom also cannot be moved *before* that early-boot mounting
> crypto-disks, as /var (where random-seed saved) can be also separate partition
> *and* encrypted.
> 
> This looks quite ... troubling.

Not at all.  Encrypted swap should be added after local filesystems are
mounted and *RNG state seeded.  (And, by implication, it should be
possible to run without swap.)

Break up and re-arrange bring-up as needed to get things right.

Also, *RNG state seeding could be done at multiple points in time.
Where there's RDRAND-like HW entropy sources then use those immediately
upon startup, else use a seed file from the RAMfs miniroot, then re-seed
when / (and /var) is (are) mounted, then re-seed when device drivers for
other HW entropy sources are loaded, then re-seed using jitter data,
then re-seed using interrupt data...

Aside: can the bootloader do anything to provide the kernel with entropy?

Also, ASLR should use /dev/urandom, and perhaps init and friends should
re-exec themselves after proper seeding.

A bigger problem on RDRAND-less tick-less systems is power management:
waking up to sample HW entropy is not an option.  This might lead to
higher latency for /dev/random on such systems.  But I think this is
manageable, besides /dev/*random should work like a periodically
re-seeded SRNG, so there should be no need for /dev/random to block once
properly seeded.

Nico
--