And about my dog, he died about a year and a half ago. But he was 19 years old, so had lived a long and happy life. I remember getting him when I was ten years old. He was a year, and he died last year when I was 28. So as sad as it was/is, I was glad to have given him a good home for as long as I was able. He is actually the dog pictured as my avatar. His passing was what prompted the use of WonderWoofy as my username for many things.
]]>Let me take the opportunity to add to the thanks by thanking the authors of the aes/aes-asm modules. Also for optimizing the code years ago when no cpu had AES hardwired.
]]>Glad you got all encrypted. I found writing the random data to the drive was what took the time in the end.
]]>So in the end, it was super easy because I went with RAID, and that made it one large drive. I used a simple passphrase for the key, but I also used a random picture of my late dog Woofy as a separate backup key. Then I saved it to a usb key for test purposes. It works great. Thanks to the aesni-intel module, I really don't see any real reduction in speed either.
I don't think that I am going to worry about the screen lockers and all that, as I don't really care. @Strike0, the reason I mentioned the security vulnerabilities of the screen lockers is because of what I have read on the internets in the past. I don't personally have an opinion of weaknesses or anything, but just thought I would ask.
Thanks cfr, Strike0, and saharchie for all the input.
OT, @cfr I am sorry to hear your laptop is an the fritz again. Is it randomly powering off again?
]]>Usually, once the blockdevice is unlocked the key-file medium can be unmounted. But if you, WonderWoofy, revisit your posts: you started thoughts on which other key-files apart from that for your root device you could put on the medium, now you turn to relocking the device on non-activity ... each of those require prolonged or repeated use of the key-file medium. So, thou shall remember more often how much passphrase typing you save when re-plugging it :-)
As for screen lockers, I think you underrate that. I write that although, just with Xorg 1.11 this year, there was a severe vulnerability in the screensaver. Plus it is not the first, just google it. However, we are using Arch and that shiny bug got rolled over particularly swiftly .. too quick for notebook thieves to ramp up their activities one would presume (something that commercial software firms dont ... err .. always achieve, i read). You know a way to circumvent the screensaver or why you consider it weak?
If you are worried that much about your data, you should use separate measures to protect it. For example, having a separate partition for that data or a further encrypted directory in your usual /home (e.g. with ecryptfs).
]]>For Fedora, yes, the installer automated the process.
For Arch, I used LVM on LUKS and that works just fine. Basically, I have three partitions: EFI, /boot, LUKS. I then have LVM on LUKS with all the rest of the partitions within the LVM. Since I only use the one disk, this is entirely straightforward and works quite elegantly - just enter password on boot and that's it.
]]>My /boot is actually separate, as it is my ESP as well. (I am one of those that simply mounts my EFI System Partition to /boot directly). So I don't ahve to typical concerns about using a bootloader that can handle encrypted stuffs and whatnot.
That is very interesting that Fedora acts that way on your computer. Is the process of installing an encrypted system with Fedora automated at all? I kind of thought that there were options to handle this within the installer. But from what I seem to gather from my reading here, if you create a crypttab (or rather add entries to the one shipped with filesystem), and you include the location of the keys, systemd should treat it similarly to the fstab, and use a generator to create systemd-cryptsetup@.service units. I foudn that there is /usr/lib/systemd/systemd-cryptsetup-generator that should handle this for you.
What is it that you ended up going with in the end cfr? For you Arch system, did you do LVM on Luks?
]]>However, that makes me wonder whether you'd need the key for more than just boot. But this might just be a quirk of Fedora. Since I'm using a different setup in Arch, I can't be sure whether it is or is not something about Fedora's system or the particular config I'm using in that case.
]]>So are you telling me that if I want to use a key-file on a USB/SD, obviously I have to have it in when I boot, but I also have to keep it plugged the whole time the conputer is operational? I was under the impression that once it was unlocked, it was unlocked. I could see if the computer is somehow set up to lock itself from inactivity, there would then be the need to once again unlock with the key.
That brings up another quick question I have been pondering. I don't know that I will actually implement this, as again, I am really just thinking about doing this because I like to tinker. But what about relocking the computer after a period of inactivity. I would imagine that simply suspending the machine itself would not result in a relocked machine. I know there are screen lockers, but it seems like a rather weak solution for someone who is going through the trouble of encrypting the entire drive. The only plausible solution that I could think up was to use hibernation. That way the computer is actually powered down and the Luks container is then locked down.
BTW, Strike0, I really appreciate you taking the time to toss ideas back and forth with me here. It is always good to get some input before venturing forth.
]]>If you don't use cryptsetup-reencrypt now to change your setup, it also introduced another just as important feature: the ability to re-encrypt later. Until this cryptsetup release there was no method to change the master key hash created during setup. Now you can.
That leads to your open question about key-files. For example: if you loose your USB key file dongle, you can now use your backup keys not only to access the machine, but also to invalidate the lost keys even if they were the Luks master keys.
But with respect to having the keys on an USB/SD, I think it is important to be clear about practical implications: Do you mind having to handle the USB dongle safely all the time, have it stick out when you carry around the powered notebook, etc.
Disk encryption is for physical security, i.e. the number one risk you use it against is notebook theft. It does not protect against any runtime logical attacks. So, you have to either keep the key-files encrypted (requiring even more hacks of standard tools to get that to work, see Luks wiki) or keep the USB/SD physically secure and separate from the machine, particularly in mobile situations (when physical theft may occur).
You get my reasoning: For the average user with one machine's Luks keys to be protected I would say key-files on those standard removable medium are simply not practical enough to weigh in against the benefits.
]]>My thoughts on key files for the non-root partitions were initially to simply have them in the encrypted root. I think this should be fine, but I also think that if I am going to have an USB provided key for the root partition, why not simply have the other key files in there as well. I think that by doing so, it would therefore be loading them into RAM, rather than having them on the SSD itself. It is not like I am going to yank out that USB key the instant I know that the root has been decrypted (nor do I think I would have the reaction time to achieve such a feat). Any thoughts on this?
Edit: Very intruiging write up there Strike0. I think I may end up putting my two drives in a RAID-0 setup and then encrypting that with LVM2 on top of that. Though, if I do that, I will not be able to use the cryptsetup-reencrypt.
]]>Honestly, the more I think about it, the more I am thinking that Luks on LVM2 might be the better way to go. Then simply include all the rest of the partitions in the crypttab. I really don't think that I would be losing any functionality of LVM2, though I would have to then resize the Luks containers in addition to resizing the logical volumes and filesystems.
Ok, with respect to your encryption that means you are going to have key-files (probably) somewhere in your encrypted root. That is fine, but also a fine difference to a pass that stays in ram.
Now, given you are not deterred by occasional breakage: If you continue this lvm->luks route, do have a close look at Milan Broz's tutorial to the new re-encryption feature. From his LVM example you will see that you might be able to encrypt without re-installation even.
]]>@strike0, I have been thinking about encryption for a while. Not necessarily because I need the security, but just because it sounded interesting. Also, I have an Intel i5 3210M, which has the AES-NI instruction set. So I figued it would be neat to try that out and see how well the aesni-intel module works. From what I have heard, it works pretty well.
As far as the lvm2 -> Luks -> lvm2, that indeed looks fairly interesting. I am not sure that I necessarily want to nest in such a fashion though (just seems kind of overkill). I surely appreciate the idea though, and will definitely keep it in mind. The reason I am a bit apprehensive about the cryptsetup-multi package is because it is based on a script found in these forums (that in itself is fine), and if you look at the date of submission and date of last update, they are one in the same. So it makes me think that there is not anyone even really maintaining the script.
Honestly, the more I think about it, the more I am thinking that Luks on LVM2 might be the better way to go. Then simply include all the rest of the partitions in the crypttab. I really don't think that I would be losing any functionality of LVM2, though I would have to then resize the Luks containers in addition to resizing the logical volumes and filesystems.
About being surprised that I am wanting to tinker with encryption, I think I just like to tinker with things in general. I think that might go for most of us around here though. I am typically not put off by the occasional tinker to breakage.
]]>My issue is that my LVM2 virtual group is actually spanning two drives.
Is this part of a RAID? If it is a software RAID you could encrypt the RAID and put a lvm2 on top of that. mkinitcpio would look like:
...sata mdadm_udev encrypt lvm2 filesystems ...