[dm-crypt] System comes up very slowly
arno at wagner.name
Sat Sep 27 12:19:18 CEST 2014
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
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?
- is cryptsetup called with "--use-random"?
- is /dev/(u)random initialized during boot?
> 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.
> 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.
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.
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
More information about the dm-crypt