With the loop device approach, you cannot. PPDD claims you can. I don't know about (T)CFS. See the sections on individual approaches below.
I don't know.
make menuconfig (or whatever), under ``Crypto
options'', say M to ``Crypto ciphers (
to the ciphers you want. Under ``Block Device'', say M to ``loopback
CONFIG_BLK_DEV_LOOP)'' and to ``General Encryption
CONFIG_BLK_DEV_LOOP_GEN)''. Don't select any other
encryption modules unless you can't live without them and they are no
longer supported by the Crypto API.
Build your kernel and modules,
make modules_install, reboot,
alias loop-xfer-gen-0 loop_gen alias loop-xfer-gen-10 loop_gen alias cipher-4 blowfish # Blowfish alias cipher-6 idea # IDEA alias cipher-7 serp6f # Serpent alias cipher-8 mars6 # MARS alias cipher-9 twofish # Twofish alias cipher-11 rc62 # RC6 alias cipher-15 dfc2 # DFC
In short, the kernel knows ciphers only by number. If you really want
to know how it works, you can
grep request_module in
If the cipher you wish to use is not in the above list, then see the
include/linux/crypto.h in the kernel source tree. There
you'll find the defines for all cipher numbers. See the directory
crypto in the kernel tree for the (file)name of the module
that implements the cipher.
You can't. At least not easily. Well, you can, but you won't be able to access your data anymore. Seriously: The passphrase is hashed and then used as the encryption key. You cannot change the password and expect the hash value (ie. the encryption key) to stay the same.
What you can do, however, is the following. Make sure, you have not currently set up or even mounted the filesystem you want to change. In the notation of section Making an Encrypted Folder you then issue:
root# losetup -e oldcipher /dev/loop0 ~user/.crypto Password : (old one) root# losetup -e newcipher /dev/loop1 ~user/.crypto Password : (new one) root# dd if=/dev/loop0 of=/dev/loop1 bs=1k conv=notrunc root# losetup -d /dev/loop0 root# losetup -d /dev/loop1If you changed the cipher, you will need to change the entry in
If you plan to do this often (and maybe you should do that), it pays to write a script for it that prompts you twice for the new password. If you are really lucky, then I will have written this for you already :-).
If you have enough free space left so that you can create the new-size file without having to remove the old first, then the solution is obvious:
user$ tar cf - -C crypto . | tar xf - -C newcrypto
ext2resize. It is, as the name
suggests, a tool that allows you to grow or shrink ext2
filesystems. And that seems to be exactly what we'll need.
Basically, what you have to do is:
user$ dd if=/dev/urandom bs=1024k count=10 >> ~/.crypto
root# losetup -e cipher /dev/loop0 ~user/.crypto Password : root# e2fsck /dev/loop0 e2fsck 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09 /dev/loop0: clean, 11/1920 files, 506/10240 blocks
ext2resizeis the new size in blocks. In our example: 10240 + 10M/1k = 20480
root# ext2resize /dev/loop0 20480
root# losetup -d /dev/loop0
No, not yet. First, some issues with memory allocations in the driver have to be resolved.
Not for all ciphers does a user-space setup tool currently exist. Please see section Patching the util-linux source for a list of working ciphers or try them all in turn.
Most probably you have compiled the kernel without
CONFIG_BLK_LOOP_DEV_USE_REL_BLOCK. As the copy now occupies
different blocks on the filesystem and you are not using relative
block numbers, the ciphers get it wrong. The only thing that will help
you now is the
ext2recover tool by
Markus Stenberg (
firstname.lastname@example.org). It will recover your
data except the first four bytes of every block. If your lost data was
only text files, that should be enough. If it was binary data it will
most probably not be enough.
You can use the ``double loop trick'':
root# losetup /dev/loop0 crypto root# losetup -e ciphername /dev/loop1 /dev/loop0This will create a new block device
/dev/loop0, where it is guaranteed that blocks are sequentially numbered starting with zero. That's the same as using relative block numbers on
cryptodirectly. If you create your crypto loop device this way, you can be sure it will still work after defrag etc.
mount does currently not support this trick, so you
will have to set up your loop devices by hand. All in all, you should
really update to a newer kernel :-)
You can't (at least not easily) when you equal "backup" with "incremental backup". If you can sleep well with image backups instead, and if you used relative block numbers for your loop device (see questions above), you can copy your file containing the crypto filesystem to wherever you want. This includes DAT tapes and removable media, as well as CDR(W).
You may want to use tricks like the ones presented above to change the cipher and/or passphrase to use another password for the backup file, dedicated to backups. That is because you have a better chance to remember one of the passwords if the other one gets lost. Also, if you change your password regularly, then how do you remember the password you used two months ago?
However, if you do not use relative block numbers, then you cannot easily copy your file around for backups. You can mount the filesystem and have it backed up as plaintext or on another encrypted device. But that will undermine your encryption thoroughly. You'll have to do something along the following lines instead:
root# losetup -e cipher /dev/loop0 ~user/.crypto root# losetup /dev/loop1 ~user/crypto-backup root# losetup -e cipher /dev/loop2 /dev/loop1 root# dd if=/dev/loop0 of=/dev/loop2 bs=1k root# for i in 2 1 0; do losetup -d /dev/loop$i; done root# cp ~user/crypto-backup /backup-mediaThis will make
crypto-backupimmune to copies (see questions further above for why).
crypto-backupneeds to be at least the same size as
.crypto, of course.