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. 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. > > 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? > - 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. > - is /dev/(u)random initialized during boot? Judging from /etc/init.d/urandom, yes. > > > 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. > > > 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? > 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 ecnrypted swap + suspend (system alive but low power) is insecure What does it mean for encrypted swap + hibernate (power is off but system state is saved to disk)? Not sure if I have the suspend/hibernate lingo right. I think those are MS-Windows terms. Ross _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
