2.6.0-test1 cryptoloop & aes

Hello,

i try to test the cryptoloop in 2.6.0-test1. I have enabled:

CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_AES=y

Then i installed the losetup from util-linux-2.12pre. When i setup the device like this:

/lib/losetup -e aes /dev/loop5 /dev/hda4

I get:

Unsupported encryption type aes

cat /proc/crypto:

name : aes
module : kernel
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16

Is the cryptoloop in 2.6.0 not usable yet?

Regards,
Christian

You need util-linux-2.12 or later.

(try ftp://ftp.cwi.nl/pub/aeb/util-linux or so)

Andries

Thanks for the tip. With util-linux-2.12 i can setup the device.

So the new cryptoloop in 2.6.0 is incompatible to the one in the international crypto patch?

I could not access my old data. So i created a new one. But when i copy some data onto it, i get:

XFS mounting filesystem loop5
Ending clean XFS mount for filesystem: loop5
xfs_force_shutdown(loop5,0x8) called from line 1070 of file fs/xfs/xfs_trans.c. Return address = 0xc02071ab Filesystem "loop5": Corruption of in-memory data detected. Shutting down filesystem: loop5 Please umount the filesystem, and rectify the problem(s)

To setup, i did this:

losetup -e aes /dev/loop5 /dev/hda4
mkfs.xfs /dev/hda4

Regards,
Christian.

I have not investigated. But at least the way to transmit the passphrase is very different. These out-of-kernel patch sets also come with patches for util-linux. Usually the resulting patched losetup uses some cryptographically strong digest algorithm to transform the passphrase into the byte array sent to the kernel.

But I left all crypto out of mount and losetup in util-linux 2.12. On the one hand we already have crypto in the kernel - no need to duplicate that. But on the other hand, the preparation of the passphrase has also been left out. The only handle put into mount/losetup is the ability to read from a specified file descriptor.
So, today, you would need something like

% get_passphrase | mount -o loop,encryption=aes -p0 dev dir

where get_passphrase is a separate, to be written, utility that reads the passphrase and digestifies.

Maybe I'll make things a bit friendlier in 2.12a, for example with

% mount -o loop,encryption=aes,getpw=/usr/local/bin/get_passwd dev dir

where mount itself forks off a process that produces the password. Comments (and code) are welcome.

Wait! /dev/loop5 is your block device, and /dev/hda4 is the file it is setup on. Now behind the back of loop you fiddle with /dev/hda4. No surprise that fails.

Andries

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

No, you should use

mkfs.xfs /dev/loop5

you want to create a fs on the loop device.

Jeff.

- --
bad pun of the week: the formula 1 control computer suffered from a race condition
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/HB8EwFP0+seVj/4RAn6DAJ9pqcYxLq2mee/RaFCBdtr3YvorlgCgkubm IY3V6WaA0K3xNnIqL0yNIQU=
=2FAW
-----END PGP SIGNATURE-----

Hello,

You are right. But i did use the /dev/loop5 device. I just wrote it wrong in the email.

I retried today on a different spare machine with the same result. Then i tried with formating the loopback device with ext2 filesystem. After filling the the device with about 1GB of data, i umounted it and did a file check. A lot of errors where reported. Something is not good there too.

Is anybody using the cryptoloop successful in 2.6.0?

Best regards,
Christian.

loop-AES works fine with 2.6.0-test1, here:

http://loop-aes.sourceforge.net/loop-AES/loop-AES-v1.7d.tar.bz2
http://loop-aes.sourceforge.net/updates/loop-AES-v1.7d-20030714.diff.bz2

Regards,
Jari Ruusu <[email protected]>

Thank you, that's the missing part. I will say that in limited use I have used aes and twofish and they seem to work correctly. I copied a bunch of data there, checked it against the md5 contents file and all data was correct, did a bunch of renames, slinks, compiles, etc. unmounted and remounted a few times. So far so good, this isn't critical data, but I'm leaning that way for my laptop.

All this with 2.6.0-test1-ac2.

Now, for the bizarre test case, suppose I did three encrypted losetups, each using a different encryption. Then I made a raid-5 array of the three loop devices. created a filesystem on the md device, and ran on that. Forget the practicality, this is a test to see of the parts are robust, can I do it and will it work?

Now make two of those filesystems losetups of NBDs. Now I can recover if any one machine is missing, no one can recover the data without compromising at least two machines. again, forget practical, this is a test and maybe has application to the devout fundamentalist paranoid. If I was going to do it I'd loopback mount the md device, too ;-)