On Sun, Sep 28, 2014 at 00:30:59 CEST, Ross Boylan wrote: > On Sat, Sep 27, 2014 at 10:32:58PM +0200, Arno Wagner wrote: [...] > > 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). It does become less secure, but not in any practical sense. This is more an information-theoretical argument and even that is a weak one. > > > > > > > > > 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. Yes, but what you deed into it is not the key, but a passphrase. And that you can change if it becomes compromised without changing the key. A "fixed key" is what youwould use for plain dm-crypt. Still, a fixed passphrase (keyfile on disk) is not that good an idea either, but sometimes the ebst you can get. > > > > 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? A dereived key reads the master-key from the mapping as in FAQ 6.10, and uses that as basis for other plain dm-crypt keys, usually just usng it directly as passphrase. The advantage is that your key never ends up on disk. > > 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. O.k., see above. These are not "fixed key", thse are "stored passprase" as what you enter is not the key. > So is your concern about fixed keys a concern about keys that are > stored on the disk vs stored in my head? Yes. > ... > > > > > > > > > > [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. That is the issue, yes. Basical;ly, you need to runt rhough part of the boot-process here and then suspend makes not that much sense anymore. It also becomes a lot slower. > > > > > 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. If you never want to change your passphrase, then SSD is probably fine. The main risk is that if your passphrase becomes compromised and you cnage it, the ond one can still be on disk in some internal pool area. This is only a concern for protection against higher-resource attackers though. If you want to ptotect yourself against a common laptop-thief, for example, using an SSD should be fine. 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
