On Sun, Jul 12, 2015 at 10:39 AM, Marc Joliet <mar...@gmx.de> wrote: > > Am Sun, 12 Jul 2015 08:48:48 -0400 > schrieb Rich Freeman <ri...@gentoo.org>: > >> If it weren't painful to set up and complicated for rescue attempts, >> I'd just use full-disk encryption with a strong key on a flash drive >> or similar. Then the disk is as good as wiped if separated from the >> key already. > > Plus you don't have to worry about reallocated sectors (which might only > contain single bit errors). Currently I'm planning on waiting for btrfs to > support it. Chris Mason recently mentioned that it's definitely something they > want to look at (https://youtu.be/W3QRWUfBua8?t=631), and it's not something > that is so important to me personally that I have to have it right this > instant. >
While some kind of native support would be nice, and likely more efficient in some ways, you could just layer btrfs on top of an encrypted loopback device. The problem is you'll need various scripts in your initramfs (or root partition if you don't bother to encrypt it) to actually set that up. In the event of a recovery situation you'll need to do all that setting up before you can run something like fsck on the disks and so on. In the event of a power loss I'd have to think through the failure modes, but I think you'd be fine as long as everything respected barriers, and btrfs/zfs already do checksuming. The typical approach is to use many rounds of encryption using a keyed-in password. That is a pretty good approach but obviously not nearly as secure as just using a completely random key with the full amount of entropy. A hand-keyed password with more entropy than the cipher uses would also be fine, but that would be a very long password (we're not just talking battery horse staple here). I guess you could just use a USB drive as your boot partition with the keys on it and keep a few copies of it, and with a decent grub setup on it that would also work for rescue purposes. -- Rich
