[dm-crypt] System comes up very slowly
ross at biostat.ucsf.edu
Sat Sep 27 21:39:30 CEST 2014
On Sat, Sep 27, 2014 at 12:19:18PM +0200, Arno Wagner wrote:
> On Sat, Sep 27, 2014 at 06:01:19 CEST, Ross Boylan wrote:
> > When my computer reboots it shows the grub menu and some initial messages
> > from the kernel loading and then waits a very long time (minutes) before
> > asking for the pass-phrase for the main partition.
> > I speculate the delay is to gather randomness for the 2 random-encrypted
> > swap partitions. However, hitting keys doesn't seem to speed it up.
> > Is this speculation reasonable?
> It depends. Doing randomness gathering right is difficult. It
> always is a trade-off between quelity and speed. If you look
> through the mailing-list archives, you find sevveral long
> discussions about this.
> That said, current cryptsetup defaults to /dev/urandom, which
> gives you randomness even if entropy is low (which may be
> insecure). We decided to use the fast option and to warn
> people in the man-pages. You can check the defaults with
> "cryptsetup --help", at the end it tells you the used
I'm running crypsetup 1.0.6 on Debian Lenny; neither --help nor
--version seems to give any info on the random source.
I'm asking becaue I'm about to convert the system to wheezy and have
the opportunity to change things. I presume this will generate an
initrd with the wheezy version, 1.4.3, which uses urandom according to
> There is a second aspect: Any sane distribution keeps some
> entropy on reboot and uses that to jump-start /dev/(u)random.
> For this some entropy is stored in a file on shutdown and
> then piped _into_ /dev/urandom on startup, hence avoiding
> entropy starvation. "man random" gives a detailed example
> on how to do that.
> You should check the following things:
> - is cryptsetup compiled with /dev/urandom or /dev/random ad
I can check the source code. Where is this determined?
> - is cryptsetup called with "--use-random"?
Is this a question about how it is called from within the initrd?
Actually, it may not matter since the man page for this version does
not indicate a --use-random option.
> - is /dev/(u)random initialized during boot?
Judging from /etc/init.d/urandom, yes.
> > If not, what might be the cause of the delay?
> A filesystem check, a raid-check, some very slow-to-detect device,
> wiping of the swap, etc.
OK. I take it entropy starvation for the swap is the only crypto
related possible cause of the delay, given that I have not switched to
slower processors. There are 2 swap partitions.
Hmm, the other thing that might be relevant is that there are 7 non-swap
encrypted logical volumes. /etc/crypttab lists root first, then the
2 swaps, and then 6 other LV's. For most of them the relevant key is
in the 2nd slot. The pass-phrase prompt is for the root device.
> > If the delay is from the encrypted swap, is there anything I can do about
> > it short of eliminating the swap? Is there any reason to avoid using a
> > fixed key for the swap? Fixed keys sound as if they should eliminate the
> > need for randomness from the system.
> Do not use fixed-keys! They will be available to an attacker.
> The whole point of random keys for swap is that they are
> non-predictable and non-recoverable, yet you do not need
> to enter them manually. Fixed keys break that.
Why are the fixed keys for swap any more available than fixed keys
for other devices/partitions?
> What you can do is to implement entropy-storage over reboot
> according to the (u)random man-page and to tell cryptsetup
> exolicitly to use /dev/urandom for the swap (--use-urandom).
> That should elieminate the wainting if key-generationf or swap
> is the issue.
> > [slightly off-topic]
> > Is it still the case that encrypted swap limits the ability to suspend or
> > hibernate and resume?
> Depends on the distro, I guess. But using encrypted swap that
> way is insecure, as an attacker can easily get access to it,
> and so it is not a good idea. For standard attacks (e.g. over
> firewire) a machine suspended/hibernated this way is wide open.
> Encrypted swap is worthless unless a full power-off is performed,
> you cannot have it easy _and_ secure in this case.
I think this means, for random-encrypted swap:
eencrypted swap + system shutdown and power off is secure
ecnrypted swap + suspend (system alive but low power) is insecure
What does it mean for encrypted swap + hibernate (power is off but
system state is saved to disk)?
Not sure if I have the suspend/hibernate lingo right. I think those
are MS-Windows terms.
More information about the dm-crypt