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. > > > > 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? Sorry, but I am not about to even look. It is a waste of time. > > - 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. As I said, 7 years old. > > - is /dev/(u)random initialized during boot? > Judging from /etc/init.d/urandom, yes. Ok. > > > > > 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. 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. 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. > > > > > 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? Fixed keys are an exceedingly bad idea in general. Derived keys 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.) > > 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 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. > 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. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
