Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Frank Steinmetzger]

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!