[dm-crypt] System comes up very slowly

Ross Boylan 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
its --help.

> 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
> default?
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 mailing list