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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
