On 6/21/07, Benjamin Schieder <[EMAIL PROTECTED]> wrote:
... So far, I've seen three ways of doing filesystem encryption: 1) simply enter a passphrase, it gets hashed to a key one-way-or-another (hashalot, luks)
sure.
2) create the dm-crypt table, encrypt it with a gpg key. on reboot, request gpg key passphrase, pipe the table back to dm-setup
i like this better. you get more entropy in your disk encryption keys, and you can optionally store the disk keys on a separate device, like USB fob. [ i like the Sony MicroVaults: http://www.sony.net/Products/Media/Microvault/usm-h.html ]
3) let the user select a cipher and then enter a passphrase (may be combined with 1, seen with loop-aes
you shouldn't need to do this for luks, since it stores cipher info in the partition header. for loop-aes i prefer to attempt to mount as AES256 and fall back to AES128 if mount fails. (or vice versa, depending on defaults.) since loop-aes doesn't indicate anything about format or encryption type on the volume, you have to manage this meta data elsewhere, and fail gracefully.
4) Let the user do it manually
this is always useful, especially when trying to recover a corrupted file system on an encrypted volume. :)
Since running `dmsetup table' still gives the required line to decrypt the block device and LiveCDs generally do not have a secure `root' account, running `dmsetup remove my_tor_home' after mount should be obvious.
what about saving changes later? require re-auth and remount?
> key scrubbing and robust key schedule (less data is encrypted per key > than the others) for loop-aes multi-v3 may provide a useful benefit > depending on your needs... The need is a Tor LiveCD.
intended usage and environment is a better description. if the LiveCD is used for a client only, no long term identity keys stored, than any of the above should be fine. (this sounds like what you envision near term). if the LiveCD is intended for running a long lived Tor server with router keys on the encrypted drive then loop-aes with key scrubbing, disk keys on an external USB device, and key management in a minimal un-networked pre-boot environment [0] would be my preference. a million other factors to consider, particularly application vulnerabilities and physical security, but at least that would put storage privacy toward the bottom of the risk list. hope that helps, 0. pre-boot auth: i like to use a small initrd to do this with a kernel configured without networking and other unnecessary device support. pivot_root, kexec, and exec init work well in this context...