On Fri, Jun 05, 2020 at 11:37:23PM -0500, Dale wrote: > Howdy, > > I think I got a old 3TB hard drive to work. After dd'ing it, redoing > partitions and such, it seems to be working. Right now, I'm copying a > bunch of data to it to see how it holds up. Oh, it's a PMR drive too. > lol Once I'm pretty sure it is alive and working well, I want to play > with encryption. At some point, I plan to encrypt /home. I found a bit > of info with startpage but some is dated. This is one link that seems > to be from this year, at least updated this year.
Encryption is a means to protect against adversaries, but in my case I mostly want to protect from incidental access. My top “use” cases: - I need to send in a broken disk for service/replacement - $DEVICE is stolen and I dont’t want the thief to access my personal stuff - the device needs to be serviced, but has its storage soldered on - protect from recovery on flash storage I’ve been running full-disk encryption with LUKS/LVM for some years now on my laptop’s SSD. I used Sakaki’s scripts to set up the kernel and initrd. The encryption password is entered during the boot process while still in the initrd phase. I don’t know of the current status of Sakaki’s stuff though (I must admit I moved away from Gentoo because portage took to much time on the laptop). On my main PC I used to have ~ on a hard disk and / on an SSD. So I left / unencrypted and symlinked sensitive files such as wpa_supplicant.conf and database files onto a directory beneath /home. Since decryption is done early at boot, there is no race condition. By now I upgraded the SSD and have both / and ~ on it, but I kept the scheme out of laziness. A week ago I got me and myself a used Surface Go (a little X86 tablet) which only has a small SSD soldered onto the board. There is no way to access or replace it. I didn’t want to use the same approach as with the laptop, because I wanted to be able to boot without a keyboard. This meant that PW entry at early boot was no option because there is no touch support at this stage. So I researched a little towards decryption at login. Ext4-internal encryption was a strong contender, because it allowed me to decrypt ~ on login, while still using a shared partitions for / and ~, which would give me more flexibility on the constrained SSD. It also encrypts filenames, but not access times (which I was OK with). Eventually though, I decided to go for more encapsulation and put ~ on a separate partition again. I set it up with LUKS and auto-mount it on login with pam_mount. On a performance not: the Surface Go has an NVME SSD and hdparm -t varies wildly between 220 and 640 MB/s. OTOH, cryptsetup benchark resulted in 1330 MiB/s for aes-cbc with a 128 bit key. Aes-xts was slower, but once I disabled all kernel mitigations¹, its throughput went up by more than 40 % and also reached 1300 MiB/s. And this is for the meagre Pentium Gold processor. So no worries in that department. ¹ Many of those vulnerabilities are about violating memory boundaries, which is most relevant for server operators and securing their users from each other. Thus, I don’t care about those on my personal machines and rather have the original performance. Exploits need to get *on* my machines first before they can snoop in my memory. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me on any social network. I hate being bi-polar. It’s fantastic!
signature.asc
Description: PGP signature
