On Sep 14, 2006, at 10:58 PM, Tracy R Reed wrote:
Stewart Stremler wrote:Um, no.Um, yes.
Um, what's the disagreement over? :P
That is perfectly fine! I *advocate* writing down passwords. In fact I write my root passwords on post-its. It is better than choosing an easily guessable password.
I, personally, would be sure to have that passphrase stored in at least two other locations aside from my head, if it's something I wasn't likely to remember.
However, if it's something I need to use every time I power the system on or log in, I'll be using it on the order of at least once or twice a day, and, at that rate, won't need any post-it reminders after the second day.
Hopefully my mind won't deteriorate. :)
Encrypting the data on a laptop isn't a bad thing -- ESPECIALLY if you're going to cross international borders and perhaps have your laptop confiscated and searched. (And how soon before the TSA starts demanding the same for domestic flights?)Indeed.
I would violently agree, but since there is no violence here yet, I'll simply agree enthusiastically.
I think that if you have an encrypted system disk, you should have TWO... and you choose which one to boot depending on the passphrase provided.That's a good idea.(And maybe a passphrase that indicates "destroy all information NOW", presumably by deleting the keys used to encrypt/decrypt the drive.)As is this one.
The serious question, though, is how to make this doable across various systems? On Linux distributions, you can set up various methods of encrypted filesystems for just about everything outside of /boot, which would, by necessity, contain the kernel and an initrd to allow you to get to the point of being able to read at least one of the encrypted filesystems. I suppose with the kernel's ability to load a new kernel in to replace itself (something I recall reading about a couple years ago actually), you could then have the kernel on the unencrypted boot partition be the bootstrap for a different kernel on an encrypted boot partition. This second kernel, then, would mount the real fileysstems using a different algorithm and passphrase. Wonder if that makes any sense at all.
Or, the simpler method: unencrypted /boot loads kernel & initrd that enable you to enter a passphrase (or passphrases) to decrypt the rest of the filesystems and start the system booting. I'm sure, with enough shell magic, it wouldn't be very hard to do something similar to Apple's FileVault, and have an encrypted filesystem image that gets mounted as your home directory at login.
So, Linux systems are pretty much covered. Does MS have some sort of filesystem encryption thingy built into XP, or only 2003 Server?
Mac OS X, unfortunately, only allows you do encrypt home directories, which should be enough, under most circumstances. I've found that it really wants to re-pack the home directory periodically, though, which can take a number of hours if you're like me and stuff everything you use on your computer into your home directory (documents, code, music, movies & videos, email archives, etc...)
As was mentioned before, though, security also encompasses backups. Not only do I not want my data to fall into the wrong hands, but I want to be able to recover my data if there's an accident that destroys the media. Do you just archive the container for the encrypted filesystem off somewhere, or do you mount/decrypt it on the source, create another encrypted filesystem somewhere else to back it up to, and then sync the contents? Say goodbye to automated backups in that case.
Finally (because it's late, I'm tired, and I don't feel like coming up with other questions yet), what if you're like me, and have most of your critical things in a revision control system? Should I wrap the repository in an encrypted filesystem on the remote server? It certainly complicates the process... I'd have to log in to the server, mount the crypto FS, do my updates/commits/etc, unmount the crypto FS, and log off the server. Certainly more involved, but if you're truly paranoid, I guess it's not all that much work. :)
So, anyone here play with FUSE filesystems? I know one of the research groups in CSE at UCSD is using FUSE with a crypto plugin to secure their raw dataset...
Gregory -- Gregory K. Ruiz-Ade <[EMAIL PROTECTED]> OpenPGP Key ID: EAF4844B keyserver: pgpkeys.mit.edu
PGP.sig
Description: This is a digitally signed message part
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
