On Tue, Dec 21, 2010 at 05:50:30PM +0000, Tom wrote: > Hello, > > I'm about to delve head down into the fascinating word of cryptography, > starting from implementing a full HDD encryption. I have to state that > I'm a recent convert to Linux and I'm still finding my way around it, so > if my questions will be a bit naive please bear the above in mind. > > Let me describe in short what I'm trying to achieve and then I will have > couple of questions. > > I will create couple of LVM partitions on top of LUKS/dm-crypt - > boot, /, usr, tmp, var, home, swap. I want to encrypt them with a key > file which will be stored in MBR of a usb-key and (possibly) add a > pass-phrase as a precaution to lost/damaged usb. And that is it, really. That is redundant. Just use the passphrase and do wthout the USB key. Also, why would you want to store a key-file in an MBR? That does not make sense. > Now for the questions: > > 1. Suspend/hibernate - I came across information that swap encrypted > with key file can/will leak it to unencrypted boot along with any other > stored keys/pass-phrases. I read as well that during un-suspend key > file/pass-phrase is stored in the actual swap making it possible for the > attacker to retrieve it (if, for example, attacker have access to the > machine through internet). Are those informations correct? I don't think so. More correct would be that you cannot suspend to disk without re-entring your passphrase on un-suspend. That could be diffilult, and would be impossible with full disk encryption. On the other hand, full-disk encrypton is already impossible without BIOS support, you alwqays have at least the kernel an some tools unencrypted. Sounds to me some people were suspending to non-tnectypted disk here. However, suspend and hibernate is not something you usually do on a UNIX-like system. Maybe just do without it? I never found a any need to do it ever and it is a security risk. > Is there a > way of encrypting swap which will allow user to enjoy the benefits of > suspend/hibernate without security breach? I know about possibility of > random key/pass-phrase with every boot but that will exclude suspend. Regular encryption and wipe the key from memory at the end of the suspend operaton. Sounds like a lot of effort for very little gain. > 2. Will I have any problems if I will decide to add a HDD to the above > set-up? Or it will be enough to extend already existing volume group > with it? Forget about extending it. That basically means repartitioning. However you can encrypt the new disk with the same passphrase. Anyways, why use LVM at all? It just complicates matters. Regular partitions do fine. > 3. I'm looking into possibility of having boot partition on external usb > key and the whole HDD would be encrypted. What would be the benefit? > Now, I'm not sure if its > possible at all and if yes, if its not beyond my current knowledge. If the USB is bootable on your cmputer, then it is rather simple. > But > assuming (for now) that I can boot the system from usb key, will it work > with LUKS/dm-crypt? Yes. You need an unencrypted initrd on the key though. > I mean whole HDD will be encrypted LVM and > unencrypted boot partition alongside with key file (either as a > plaintext or hidden in MBR) will be on usb stick. Forget hiding anything. It is just not effective against any halfway competent attacker. And, as I said, forget about the keyfile. LUKS already has an encrypted master-key in the header. Your protection is the passphrase. > And that will be all, I think. Thanks everyone for your time and > patience! No problem. Also, *read the FAQ*, especially the section about backup and recovery from overwtitten LUKS headers. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans 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
