When would one use this?<p>When I install Fedora, it gives me the opportunity to encrypt any file system other than /boot. Since this requires you to enter the password at boot, that's good for a laptop, probably bad for a server.<p>You need root privilege to mount a loopback file system. Either (a) you've got the root password (b) the admin has given sufficient sudo privileges or (c) you use pam_mount to mount the encrypted filesystem (probably as your home directory). Am I missing other scenarios?<p>The trouble with the pam_mount scenario is that the key for the file system needs to be based on your login password. Either your account creation process involves telling the admin your password, or someone's built a collection of self service tools I'm unaware of. Changing your password also means building a new encrypted filesystem, which again involves giving the admin the new password, or invoking self service tools I'm unaware of.<p>If there are other scenarios in which to use this kind of encrypted file system, I'd appreciate hearing about them.
The script initializes the image from /dev/zero, which means that an attacker can tell which blocks of the filesystem image are data and which are empty. Unless you really can't afford to wait the minute or so for it to finish, use /dev/urandom - or /dev/random, if you've got access to sufficient entropy (did you pay extra for a hardware random number generator?).
This uses cryptoloop, which SHOULD NOT BE USED IF YOU WANT STRONG SECURITY. See: <a href="http://mareichelt.de/pub/texts.cryptoloop.php" rel="nofollow">http://mareichelt.de/pub/texts.cryptoloop.php</a><p>You can do better with LUKS or Truecrypt. LUKS comes with most distributions. It comes with a handy wrapper called "cryptsetup" which does the setup for you.
I'd use AES128, it's more secure (well, so far anyway). There's a weakness in the AES256 algorithm that makes it weaker then AES128. Not weak enough that I would really be worried , but if you have the choice...
A coworker of mine pointed me to EncFS, which I think is generally a better idea because you don't commit to sizing in advance: <a href="http://www.arg0.net/encfs" rel="nofollow">http://www.arg0.net/encfs</a><p>I have been satisfied with its performance used as the backing store for virtual machine images, though not having a dual-core may be problematic.