Re: [dm-crypt] System comes up very slowly

[Arno Wagner <arno@wagner.name>]

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
CPRNG. 

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

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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