Encrypt data in Linux/Unix
|
|
|
Comments (4)
Aha, a subject very near and dear to my heart.
First, you will notice a slow-down with long-duration disk/file access. Examples: recursive grep, fsck, and updatedb. I wouldn't want to play any hi-def MPEG's or Theoras from an encrypted volume without an SMP system.
If you have lots of RAM, turn off swap and put /tmp into tmpfs. By convention and best practice, it shouldn't be persistent anyway. Persistent ephemeral data should be somewhere in /var.
If you have a mirror partition for /home somewhere, make sure it's encrypted as well. Another good idea is to make it a different filesystem. Example: /home is ext3, /backup/home is XFS or JFS.
But here's the drawback: While the machine is live, /home is unlocked and open to anyone who can get root privileges on the system. It's an all-or-nothing deal. (Not automatically the case for the backup /home; it can be unmounted when not in use.)
SELinux can afford some protection against compromised processes, but that doesn't apply to off-line backups. Are they protected as well, with a different cipher/passkey?
So much paranoia, so little hope that it's baseless.
First, you will notice a slow-down with long-duration disk/file access. Examples: recursive grep, fsck, and updatedb. I wouldn't want to play any hi-def MPEG's or Theoras from an encrypted volume without an SMP system.
If you have lots of RAM, turn off swap and put /tmp into tmpfs. By convention and best practice, it shouldn't be persistent anyway. Persistent ephemeral data should be somewhere in /var.
If you have a mirror partition for /home somewhere, make sure it's encrypted as well. Another good idea is to make it a different filesystem. Example: /home is ext3, /backup/home is XFS or JFS.
But here's the drawback: While the machine is live, /home is unlocked and open to anyone who can get root privileges on the system. It's an all-or-nothing deal. (Not automatically the case for the backup /home; it can be unmounted when not in use.)
SELinux can afford some protection against compromised processes, but that doesn't apply to off-line backups. Are they protected as well, with a different cipher/passkey?
So much paranoia, so little hope that it's baseless.
I have little need for encrypted filesystems. If I do, I use encfs to create a temporary filesystem somewhere, use it and then discard it. I use GPG to encrypt data that needs storing permanently, including all my backups. And yes, I have my GPG printed out on paper and in a safe far away from my home :-)
On acid-free paper, I hope.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post

I'm doing this on a laptop, and having a drive with data that's fully protected in case the hardware is stolen is something I've been reluctant to do without up until now.
So far performance doesn't seem worse than w/o encrypted LVM. I haven't done any a/b tests, but I can't detect any slowdown.
I also like the encryption feature in Puppy Linux, but I've got too much e-mail at this point, and it won't all fit in the pup_save.
Is it easy to set up a fully encrypted drive in your favorite OS? Or do you think full encryption is too much, and only /swap /tmp and /home need to be encrypted and if so, how easy is it to do that; one of the main advantages of fully encrypted LVM in Debian/Ubuntu is that the average dunce (i.e. me) can do it without geeking out too much.