[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [ANNOUNCE] ROCKate Tor LiveCD V0.4.0.0
On 6/21/07, Benjamin Schieder <blindcoder@xxxxxxxxxxxxxxxxxxxx> 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
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:
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
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
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  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...