I'm sorry, but to be frank, I think you're going about this the hard way. I looked through that guide, and it seems quite complex. Granted, I don't have any experience with the software RAID tools, but this still seems like overkill. It also seems less future-proof to me, which is something you should consider when getting ready to lock your data up in a certain encryption scheme. The guide also says, "Loop-AES is more secure than dm-crypt (and possibly faster)," but I don't know if that's true. The dm-crypt system is pretty standard, it uses AES, and you can use GPG keys with it as well.
I recommend that you abandon this particular guide, and Loop-AES, and use cryptsetup, perhaps also with LUKS (in fact, there's even a guide for this on the same site you've been using). encfs is also an option, but is a very different way of storing the encrypted data. cryptsetup is a standard tool, very simple, and quick. It can boil down to this, basically: (use whatever "if" you want; /dev/zero is quick, but if you're really paranoid, use one of the random devices) # dd if=/dev/urandom of=/path/to/encrypted/loopfile bs=1M count=nummegs # losetup /dev/loop/0 /path/to/encrypted/loopfile # cryptsetup create vault /dev/loop/0 (give your passphrase; read the man pages if you want to use a keyfile instead, but that means lost key=lost data) # mkfs.ext3 /dev/mapper/vault # mount /dev/mapper/vault /mnt/vault (Of course, standard warnings about dd apply; be careful, it can be a scalpel or a sledgehammer to your data.) Notice that you use dd before you create the loop device, then you create the encrypted device-mapper device before making the filesystem, and finally you mount the filesystem. I believe the cryptsetup in Debian also supports LUKS now, but you may want to make sure that LUKS isn't going to make one more on-disk format change before you decide to use it. And again, I'd look into encfs before making a final decision. Again, keyfiles are an option to increase security, but they also increase the risk of losing your data. Make sure you keep multiple backups of the key in safe locations. And again, think of the future. Using non-standard tools also increases the risk that in the future, if you upgrade or have to reinstall your OS, something won't get recreated exactly the same way, and will make it harder to access your data. If you still want to go through with this loop-aes guide, then it looks to me like you're running losetup before creating the loopback file with dd. And--I just noticed this--if you're planning to use an entire partition or array for your encrypted device, you don't even need a loopback device. cryptsetup can use a partition or entire disk directly. As far as I know, loop-aes is deprecated (and the fact that it's not in Debian proper lends credence to that, I think). Well, sorry for being so long-winded and disorganized, but I hope this helps you get it working. Good luck. Adam On Thursday 09 March 2006 13:50, you wrote: > >Are you losetup'ing and *then* running dd to create the file? From > > reading > > >your post, I get that impression. If you are, you should create the > > file > > >with dd, and *then* losetup it. > > I am following: > http://deb.riseup.net/storage/encryption/loop-aes/ > > > Here is a longer post I did on linux-crypto > > >What you said was inconsistent. loop3/md4 vs. loop1/md2 > > I will do that. Just as a "sort out" 3/4 were the examples on the page. > 1/2 was what I actually used. > > I start by rebooting my system to be sure. > > cookiemonster:~/VMware# reboot > [removed useless info about system shutting down] > > We log in, and I recreated the array (after zeroing superblocks) > mdadm --create /dev/md2 --chunk=64 --level=raid1 --raid-devices=2 > /dev/hde1 /dev/hdf1 > > > cookiemonster:~# mdadm --detail /dev/md2 > /dev/md2: > Version : 00.90.01 > Creation Time : Thu Mar 9 20:25:02 2006 > Raid Level : raid1 > Array Size : 80418112 (76.69 GiB 82.35 GB) > Device Size : 80418112 (76.69 GiB 82.35 GB) > Raid Devices : 2 > Total Devices : 2 > Preferred Minor : 2 > Persistence : Superblock is persistent > > Update Time : Thu Mar 9 20:25:02 2006 > State : clean, resyncing > Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > > Rebuild Status : 2% complete > > UUID : 5e24575f:df3b5a81:f2a68636:ff7f6e2b > Events : 0.415 > > Number Major Minor RaidDevice State > 0 33 1 0 active sync > /dev/.static/dev/hde1 > 1 33 65 1 active sync > /dev/.static/dev/hdf1 > cookiemonster:~# > > We have plenty of memory > cookiemonster:~# free > total used free shared buffers > cached > Mem: 3116936 170160 2946776 0 6296 > 73592 > -/+ buffers/cache: 90272 3026664 > Swap: 1951888 0 1951888 > cookiemonster:~# > cookiemonster:~# modprobe loop > cookiemonster:~# head -c 15 /dev/urandom | uuencode -m - | head -n 2 | > tail -n 1 | losetup -p 0 -e AES256 /dev/loop1 /dev/md2 > > So far, all is well, log shows: > Mar 9 20:29:24 cookiemonster kernel: loop: loaded (max 8 devices) > Mar 9 20:29:24 cookiemonster udev[4958]: creating device node > '/dev/loop0' > Mar 9 20:29:24 cookiemonster udev[4965]: creating device node > '/dev/loop1' > Mar 9 20:29:24 cookiemonster udev[4972]: creating device node > '/dev/loop2' > Mar 9 20:29:24 cookiemonster udev[5007]: creating device node > '/dev/loop3' > Mar 9 20:29:24 cookiemonster udev[5008]: creating device node > '/dev/loop4' > Mar 9 20:29:24 cookiemonster udev[5009]: creating device node > '/dev/loop5' > Mar 9 20:29:24 cookiemonster udev[5010]: creating device node > '/dev/loop6' > Mar 9 20:29:24 cookiemonster udev[5011]: creating device node > '/dev/loop7' > > cookiemonster:~# dd if=/dev/zero of=/dev/loop3 bs=4k conv=notrunc > 2>/dev/null > cookiemonster:~# losetup -d /dev/loop1 > cookiemonster:~# losetup -F /dev/loop1 > Password: > cookiemonster:~# mkfs.ext3 /dev/loop1 > > And THEN I get the below (but mind you, the FS create continues, until > "Writing inode tables: Done" and then the terminal freezes. But > processes starts to dies with OOM ( still have plenty RAM left). > cookiemonster:~# free > total used free shared buffers > cached > Mem: 3116936 983468 2133468 0 819064 > 45896 > -/+ buffers/cache: 118508 2998428 > Swap: 1951888 0 1951888 > cookiemonster:~# > > Mar 9 20:32:46 cookiemonster kernel: Out of Memory: Killed process 4256 > (mysqld). ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
