[dm-crypt] System comes up very slowly

Ross Boylan ross at biostat.ucsf.edu
Sun Sep 28 00:30:59 CEST 2014


On Sat, Sep 27, 2014 at 10:32:58PM +0200, Arno Wagner wrote:
> On Sat, Sep 27, 2014 at 21:39:30 CEST, Ross Boylan wrote:
> > 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
> > > CPRNG. 
> > 
> > I'm running crypsetup 1.0.6 on Debian Lenny; neither --help nor
> > --version seems to give any info on the random source.
> 
> Aehm, that is so incredible historic that helping you becomes 
> very hard. This version is more than 7 years old.
>  
> > 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.
> 
> Upgrade and see whether the problem goes away. If not, ask 
> again, but it likely will be something else if urandom is the
> default.
Sounds good.

.....

> > 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.
> 
> Ah, that may be it. Unlocking a LUKS volume takes checking key-slots
> and, due to hash-iteration, each keyslot check takes a certain time.
> These days, the default is 1 second for each key-slot, and some 
> additional time for the master-key. This can be increased on
> creation and at compile-time though. Also, mounting can take 
> quite some time depending in volume size. Your 7 volumes can
> easily take the 2 Minutes you observe.

I don't think it's the mounting since the partitions can't be mounted
until they are decrypted, and that can't happen until after I enter
the pass-phrase.  Also, I suspect debian does all the decryption
first, and then the mounts.

The wait seems like forever, and could be 5 or 10 minutes.

> 
> What you can do to determine iteration time is to look at 
> Key-slot "iteration" parameter in the output of "luksDump"
> and then do a reference test, e.g. with a loop-device as in
> FAQ Item 2.6 and with explicitely specified ---uter-time 1000
> (1 second). That should tell you how long a key-slot needs 
> to be checked.
> 
> Unfortunately, there is no way to change iteration count.
> If it is indeed too long, the simplest way is to backup the 
> data and re-create the volumes woth a different --iter-time
> or the current 1 sec default. Longer times do not really
> add much security.

Since I'm doing a fresh install and then restore I can change
anything, since I'm building new partitions and file systems.

I was encrypting selected partitions/logical volumes, but I'm probably
going to put the crypt right on top of RAID this time.  This means
there will be only one thing to unlock.

One reason I went with the old scheme is that I thought encryption
became less secure the bigger the area encrypted.  However, I don't
see anything about that in the FAQ (except for the 2TB limit on some
encryption schemes).

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

I must be misunderstanding, because it seems to me any LUKS device
that is not random encrypted has fixed keys.

> > > 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?
> 
> Fixed keys are an exceedingly bad idea in general. Derived keys

I don't know what a derived key is.  Like
http://en.wikipedia.org/wiki/Derived_unique_key_per_transaction,
except not  transactional?  6.6 of the FAQ?

> are acceptable, but fixed keys can end up unintentionally
> in all sorts of places. Do not use them. (I gather the fixed keys
> are placed on the encrypted root partition.)

fixed keys, in the sense of --key-file for the other partitions, are in
the encrypted root.  I am aware they are sensitive.

So is your concern about fixed keys a concern about keys that are
stored on the disk vs stored in my head?

...

> > > 
> > > > [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
> 
> Yes. Key gone, no way to recover anything from swap.
> 
> > ecnrypted swap + suspend (system alive but low power) is insecure
> 
> Yes. Key is in memory.

I had assumed one would have to reenter the pass-phrase on wakeup.
Though now that I think of it, that's non-trivial since the code to
get the pass-phrase and cryptsetup itself would need to be in memory
that wasn't encrypted.

> 
> > What does it mean for encrypted swap + hibernate (power is off but
> > system state is saved to disk)?
> 
> If you can wake up without giving encryption keys again, the
> key is somehwere on disk.
> 
> > Not sure if I have the suspend/hibernate lingo right.  I think those
> > are MS-Windows terms.
> 
> They are. If you want security, it really is better to just 
> have faster boot and not suspend or hibernate. 

The easiest way to have faster boot is to use SSD, but the FAQ
indicates the security of SSD's is unclear.

Ross


More information about the dm-crypt mailing list