On Fri, 16 Sep 2016 at 20:41:29 +0200, Guilhem Moulin wrote: > On Tue, 29 Oct 2013 at 13:09:08 +0100, Milan Kral wrote >> The problem is that in /etc/rcS.d the scripts S07cryptdisks-early, >> S09cryptdisks are run before S13urandom. We are trying to read from >> /dev/urandom before the Linux random number generator is properly >> seeded. This can lead to predictable encryption key for the swap >> partition. > > That's problematic, indeed. For the record, the situation doesn't seem > to be better with systemd:
Turns out that's incorrect: systemd-cryptsetup-generator(8) adds an
“After=systemd-random-seed.service” dependency when the key file is
“/dev/urandom”.
https://sources.debian.org/src/systemd/239-5/src/cryptsetup/cryptsetup-generator.c/#L118
So for targets with random key, the pseudorandom number generator has
already been re-seeded by the time the deiced is mapped. This can be
double checked with
systemctl cat systemd-cryptsetup@$CRYPTTAB_NAME.service | grep ^After=
> (Note the “random: nonblocking pool is initialized” at the very end,
> long after initializing swap, even after login.)
That's because `systemd-random-seed load` only writes into /dev/urandom
hence according to random(4) only adds data to the pool but doesn't
increment the kernel's entropy count. Thus subsequent reads from
/dev/random still block, and reads from /dev/urandom yield kernel
warnings.
Discovered this after asking upstream for a new option `--random-key` with
getentropy(3) semantics, cf.
https://gitlab.com/cryptsetup/cryptsetup/issues/402 .
--
Guilhem.
signature.asc
Description: PGP signature
