[148007] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Nov 4 23:34:29 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 4 Nov 2013 16:51:25 -0600
From: Nico Williams <nico@cryptonector.com>
To: Yuriy Kaminskiy <yumkam@gmail.com>
In-Reply-To: <l58v36$gjo$1@ger.gmane.org>
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
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
--
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
