how to encrypt a hard drive: what are the pitfalls? what type of encryption?
 

I have virtually zero experience encrypting hard drives. I only encrypted an Artix Linux install once, but I didn't really pay much attention to what I was doing. The only thing I learned is that there is a significant wait for the hard drive to mount every time I boot, since it's extrapolating the encrypted content. At least....I think. Maybe there's another explaination. And that's why I'm making this thread.

I want some basic suggestions which type of encryption to use for an external hard drive? And what pitfalls could ensue? Like, forgetting your password, but that's one I can think of myself, so I'm hoping someone more experienced would know other pitfalls.

Also, what about mdadm/raid compatibility? I choose mirror in case one drive fails, I can still recover. In a single drive failure scenario, what complications can arise?

Also, is there some Slackware specific encryption methods that do not apply to other distros? Slackware is my primary distro, but I also like Artix.

Also, what tools are recommended to test hard drives of their reliability before committing them to encryption?

I want to implement this on a SARPI 15.0 install. I want to do full disk encryption, unless that's not a good idea.

I don't have a ton of experience, but I do encrypt my laptop drive and my internal and external backup drives. For the laptop, I follow the instructions given for full disk encryption (except for /boot) in the Slackware release, which is in README_CRYPT.TXT. I use LVM as well, following the instructions in README_LVM.TXT. LUKS and cryptsetup work great for encrypting and decrypting.

It does take a little time to decrypt the key initially, but once the drives are mounted the speed difference between drives that use encryption and those that do not is not noticeable, even when using encryption algorithms other than AES. (AES has hardware acceleration in many CPUs.) The main pitfall is losing your password or mangling your LUKS headers, so you need to back those up several places for safekeeping. Cryptsetup will help with copying the LUKS headers to files.

With my internal backup drive pairs I encrypt both and then use btrfs with RAID1, for drive mirroring. Btrfs works well for backups, but if one drive in a mirrored set goes bad, it'll be a pain to recover from (though I understand that it's not impossible). I don't have experience with mdadm so I can't answer questions about that.

Some time ago, I wrote a litte how-to for encrypting a USB key: how-to-encrypt-a-usb-key-with-cryptsetup
I use it when I have a new USB key to encrypt.
It should also apply to external hard drive.
Instructions to backup the LUKS header are included.
Hope this helps.

I'd go with LUKS encrypted containers or ecryptfs's ~/Private setup and avoid full disk encryption because:

• If an update to the tool breaks it, you're stuck
• If the underlying crypto lib updates with an incompatible change, you are stuck (looking at you, openssl). This happened to me once with libgcrypt
• You can't use an encrypted system to fix an encrypted system that won't unlock
• The chance for a non-booting system increases with full disk encryption
• People lose/forget passwords

Unless you have a very special use case, like you are deep behind enemy lines and your life depends on it, I'd stay away from full disk encryption. A special setup on a USB stick, maybe for travel, would be different, as well as a an external HD purely for storage, but I'd not bet my entire main system on always being able to unlock the encyption. Consider: how many times have you seen an application break because it needs to be recompiled against the new libraries you just installed?

You may find this documentation helpful on Slackware ARM/ARM64. I wrote it up while focused on the Pinebook Pro last year. It is the same process, with different block devices, on the raspberry pi 4 vs rockpro64. Somewhat of a rewrite of the README_CRYPT.TXT from Pat.

Slack docs: disk_encryption_slackware_aarch64

I'd recommend using a 256 bit key size rather than a 512 bit. 512 bit keys are just plain over kill IMHO. Also do not use a SD card as your encrypted root disk. Plug in two of the same drives to the usb 3.0 ports. Boot from the SD card and have your rootfs on the external disk.

RAID 1 is what I use on the Honeycomb LX2k, also arm64. I have tried it with and without RAID disk encryption. I did not benchmark read and writes. The drives did appear to constantly be "behind" with disk sync. This was not the case with a stand alone RAID 1 or a stand alone LUKS + LVM configuration.

I'm not going to encrypt the system disk, just external storage. I mean, so long I still have the "old" version even if the new version breaks it, wouldn't I be able to access the disk? Am I not understanding something?

The only downside I've found so far is that you can't use autofs automounting as something will need to have unlocked the luks container first. I think most the desktop environment file-managers/volume-managers do this for you these days, but if you're a cli jockey that uses autofs then its a limitation you have to live with.

Encrypting the entire hard drive is, in my opinion, unnecessary. I only encrypt my external SSD and NVMe with TCplay AES/Serpent/Twofish. - On this encrypted SSD, all of my important data is stored. This external SSD can also be decrypted very easily with Windows.