>>4207The old saying is true: Just because I'm paranoid doesn't mean they're not out to get me.
A good firewall between you and the internet isn't paranoia though. It's just common sense. You wouldn't leave the front door of your house wide open at all hours would you? Lettings every one that passes by have a peek inside. You wouldn't have spiders, snakes, bugs, mice and human thieves in. That's why you have a door and a lock on the door. The lock might be easy for a practiced thief to break. But it keeps honest people honest and if you're having break ins all of the time you can reinforce the lock or add bars to the windows or something like that.
Full disk encryption is just common sense. That way if your laptop/computer/HDDs are stolen the thief doesn't get easy access to everything contained on them. It should have been the default long ago in all OSs. It's terrible that so many OSs don't have an easy way to set up FDE. Some are getting there but they're usually easy to by-pass and people don't bother with them anyway. Or they only encrypt certain files on the disk. Which isn't the best idea because if everything around them aren't encrypted it makes it easier to break the (usually weak) encryption on those few files that are. Not to mention most easy-to-use encryption schemes are easily broken by their design. Since these companies work hand-in-hand with law enforcement.
The ideal set-up for encryption is two factor option. Where you need some kind of key and a password to unlock the storage devices. This is the hardest kind to setup and pretty much nothing ships with it on by default. No one is selling pre-installed OS+hardware with that type of set-up either. So you end up having to do it yourself and it's a huge pain in the ass. Only Linux really supports it as well. OpenBSD/FreeBSD is getting there. But you still can't run a set-up with private key+password to unlock+detached headers. Detached headers is really important. With headers on the storage device it's easy to tell that encrypted partitions exist. With them outside of the storage device (usually on a thumb drive) the internal storage device simply looks like truly random data. Which allows you to claim that you just wiped the disks and nothing still exists on them should you be forced to testify in a court of law.
Oh all the OSs I've tried lately OpenBSD has the more easy to setup encryption scheme for FDE. You get an option at install time to either use a password or store a private key on another device like a thumb drive. But it doesn't allow you to do both yet nor does its file system allow you to detach the headers. I think they're working towards improving it so maybe the situation will change soon.
Aside from OpenBSD the Gentoo distro has the most documentation for setting up what I consider good FDE. Many claim Arch is better in this respect. But the issue is it relies on certain tools I consider to be horrible (systemd and friends). Which I do not allow on my own devices for a lot of reasons I'm not going to rant about now. The short version of the rant is: You can't trust the developers of that software so you shouldn't trust the software itself. We're talking about an init system that was handing out root to any user with a number in their usernames after all. In addition to it being a ton of code running as PID1 for no reason with a horrible track record for bugs/bug fixes.
Anyway, if you want detached headers+key to unlock+password I suggest going to the Gentoo wiki and reading some of the guides for doing it without systemd+fedora tools. They've got their own software to handle things like initramfs. They're much better than what all the other distros are shipping.
I personally use chain unlocking and no kernel on the actual device. By that I mean my boot up looks something like this:
1) Insert thumb drive with copy of kernel+private encryption key
2) System boots from thumb drive
3) Kernel is loaded from thumb drive and unlocks primary system partition on SSD once password is input
4) Once kernel boots into console it searches now decrypted SSD for other private keys to unlock HDDs used for actual storage of non-system files
5) HDDs are unlocked automatically using those keys. Can have another password prompt here for each one if you really want
I've also done it another way. Where key on thumb drive unlocks SSD system drive. SSD system drive unlocks HDD1. HHD2 is unlocked by key stored on HDD1. Rinse and repeat for each and every disk until they're all unlocked and up and running. I don't do this anymore because now I have all the HDDs in a RAID pool. So they just function as one big disk.
Keys can be anything. You can generate random blocks of data with /dev/urandom to make keys. Or you can use other files like random images. You can also have multiple keys/passwords to unlock your encrypted devices. You can also store your keys encrypted on a disk with a password to decrypt them. Which is what I do on my thumb drive that holds the kernel+initial private key. Even if you stole the thumb drive and got a copy of the key it's useless unless you have the password.
Typically, I have at least two keys for each drive. The first key is a random block of data I've generated with /dev/urandom. The second key is something like an image of my favorite SHABs. Typically slightly modified with something injected into the file to make it unique from the one being circulated on the wider internet.
This way unlocking is mostly automatic with the first set of keys. But if I lose the thumb drive I can still access the data on the disks using the other keys. Which I've backed up in several places. I have those keys (images) shoved in a massive folder with thousands of other images. So they don't look like they're important to anyone that might get access to them. Just looks like I scraped the local booru and have a local copy of it for my own fapping purposes.