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