From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Sat, 27 Sep 2014 12:19:20 +0200 (CEST) Received: from gatewagner.dyndns.org (77-57-44-24.dclient.hispeed.ch [77.57.44.24]) by v6.tansi.org (Postfix) with ESMTPA id 2322134FA001 for ; Sat, 27 Sep 2014 12:19:19 +0200 (CEST) Date: Sat, 27 Sep 2014 12:19:18 +0200 From: Arno Wagner Message-ID: <20140927101918.GA10333@tansi.org> References: <58008.10.0.2.3.1411790479.squirrel@biostat.ucsf.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58008.10.0.2.3.1411790479.squirrel@biostat.ucsf.edu> Subject: Re: [dm-crypt] System comes up very slowly List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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