just a small encrypted filesystem?

[lytenyn]

Hi

I just browsed a bit through the crypo-api/encrypted-filesystems-threads and obviously it is rather complicated to encrypt your whole harddisk (not to mention performance - which is rather seldomly discussed)

So I wonder: what's the best method to have a small encrypted filesystem (preferably in a file, not in a partition) in your home-directory for important things?

The easiest way is probably just to encrypt a 'normal' filesystem-file with gnupg .. but this is rather complicated and leaves traces on your harddisk ..

The problem with cryptoloop etc is that I need to manually patch my kernel etc ..

So my question is: Do you know an easier method? What would you suggest? Performance is not an issue, as the filesystem could be for storage and rather small .. in contrast to encrypting your whole root-partition.

lytenyn

[ewan.paton]

from what ive heard it adds 2-3% to the cpu load depending upon processor but mosern cpus are so powerful i doubt it would be noticable. one thing to remeber is if the swap partition is used for any encripted file it will be recoverable unless swap is also encripted.

if you actually need encription{1} the the brute force aproach of the whole disk is probably best, an ideal system would one which booted from a removable usb drive which had a kernel and keys on it to acces an encripted disk

{1} i read up on it as it was interestin but couldnt give a monkeys who sees whats on my pc

[sapphirecat]

(not to mention performance - which is rather seldomly discussed)

Well, I can send data (one way) to or from disk at 20-30 MB/s, and encrypt with aes-256 at around 100 MB/s. [80GB 7200rpm 2MB cache Seagate Barracuda IV (ATA-100) disk, and a 2.0GHz Athlon XP 2400 with 266FSB proc.]

The problem with cryptoloop etc is that I need to manually patch my kernel etc ..

Not to mention the kernel help (at least for 2.6.4) warns that cryptoloop isn't safe for journaling filesystems.

So my question is: Do you know an easier method?

Nope. Back in the Day(TM), there were people working on (t)cfs, a (transparent) crypto filesystem, but I think they've been dead since 2.4.0 hit the servers. The tcfs homepage for instance doesn't have any real news since 2001, and offers downloads for 2.0 and 2.2.

[IvanHoe]

Well, here's how to do a loopback crypto device:

First, you need cryptoloop support in the kernel...

Code: Select all

Device Drivers  --->
        Block devices  --->
                <*> Loopback device support
                <*>     Cryptoloop Support

If you use a 2.6 kernel then it has it by default (no patching required), just go into menuconfig and select it. If you use gentoo-sources-2.4.x then just put "crypto" in your USE flags, re-emerge the kernel sources, make loopback and crypto selections in menuconfig then re-build your kernel.

You'll also need to select one or more cypher algorithms...

Code: Select all

Cryptographic options  --->
        <*> AES cipher algorithms

Next you'll need a container. This can be a file or a disk partition. To create a file use dd like this...

Code: Select all

dd if=/dev/urandom of=~/cryptofile bs=1024k count=100

This will create a 100 megabyte file named cryptofile in your home folder (and it will take some time to do it).

To prepare a disk partition, use something like...

Code: Select all

cat /dev/urandom > /dev/hda4

Where /dev/hda4 is the disk partition. WARNING: this will obliterate anything on that partition!

Now you need to attach the file or partition to a loopback device...

Code: Select all

losetup -e aes-256 /dev/loop0 /dev/hda4
    ... or ...
losetup -e aes-256 /dev/loop0 ~/cryptofile

losetup will ask you for a password. Be very careful to input the correct password as it will only ask you once!

Now you create the file system on the loop device...

Code: Select all

mke2fs /dev/loop0

and mount it...

Code: Select all

mkdir /mnt/crypto
mount -t ext2 /dev/loop0 /mnt/crypto

To unmount it (and disconnect the loop device) use...

Code: Select all

umount /mnt/crypto
losetup -d /dev/loop0

It's a really good idea to disconnect the loop device after you first create the file system, then re-connect and mount to verify your password before copying a bunch of files.

[Roguelazer]

You had a couple of errors there.

Firstly:

The losetup is different in the new version. It should read as this:

Code: Select all

losetup -e aes-256 /dev/loop0 /dev/hda4
    ... or ...
losetup -e aes-256 /dev/loop0 ~/cryptofile

Secondly:

Unmounting should read as this:

Code: Select all

umount /mnt/crypto
losetup -d /dev/loop0

Thirdly, you should note that you need to be superuser for the losetup steps.


Fourthly, reconnecting steps are this:

Code: Select all

losetup -e aes-256 /dev/loop0 ~/cryptofile
mount -t ext2 /dev/loop0 /mnt/crypto

Note the change from the initial connect to the new one.

[IvanHoe]

You had a couple of errors there.

Firstly:

The losetup is different in the new version. It should read as this:

Code: Select all

losetup -e aes-256 /dev/loop0 /dev/hda4
    ... or ...
losetup -e aes-256 /dev/loop0 ~/cryptofile

Secondly:

Unmounting should read as this:

Code: Select all

umount /mnt/crypto
losetup -d /dev/loop0

Thanks Roguelazer, typos are now fixed.

Fourthly, reconnecting steps are this:

Code: Select all

losetup -e aes-256 /dev/loop0 ~/cryptofile
mount -t ext2 /dev/loop0 /mnt/crypto

Note the change from the initial connect to the new one.

Sorry, I assumed someone doing this would know not to create the file system again or that they didn't need to create the mount point in /mnt again either.

[edit] I just noticed my status is now "Guru". I guess I'll have to stop making idiotic statements or asking dumb questions.

[Roguelazer]

I even went a step farther.

http://www.roguelazer.com/files/cryptocontrol.tar.gz

A set of three scripts that automate creating, mounting and unmounting an encrypted file. Yay for me!

[snutte]

I even went a step farther.

http://www.roguelazer.com/files/cryptocontrol.tar.gz

A set of three scripts that automate creating, mounting and unmounting an encrypted file. Yay for me!

Please rename it to .bz2 since its not a gz file. Took me a minute to figure that one out.

[Quantumstate]

(Actually, it is a tar.gz . Thanks Rogue)


I'm unable to mount my older DVDRAM encrypted backup disks. Made them in Mandrake with kernel2.6.3 and AES256, under UDF.

I now have Gentoo kernel2.6.5-r1, and can
# losetup -e aes-256 /dev/loop1 /dev/sr1
Password:
#
(meaning, password read from dvdram & accepted) but:
# mount -t udf /dev/loop1 /mnt/dvdsafe
... a pause of 3 seconds ...
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
or too many mounted file systems

So after a day of research (since I need these backups) I recompiled gentoo2.6.5-r1 with the packet-2.6.5 patch added. Into make xconfig I pull my custom config-265 and set:
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_COMPRESSLOOP=y

CONFIG_UDF_FS=y

Also set the(newly-appearing):
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set

Compile goes fine, and on reboot I now automatically have new devicen:
/dev/pktcdvd0
/dev/pktcdvd1

As I understand, I cannot write sr0 and sr1 directly (In my case these are a scsi cdrw & dvdram respectively) so I tear down the previous loop and
# pktsetup /dev/pktcdvd1 /dev/sr1
# losetup -e aes-256 /dev/loop1 /dev/pktcdvd1
... and am rewarded with ...
/dev/pktcdvd1: Input/output error

One possibility is, as I understand it loop devices present with -bs 1024 whereas dvdrams are 2048. But there's no way to specify bs in loopsetup, and mounting with -o bs=2048 gives
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
or too many mounted file systems

Any ideas? Why did I not need a patch with Mandrake, and it worked with the above loop settings? I'd like to use any new mechanisms as a matter of course, but must recover some older files first.

[Quantumstate]

# strace mount -t udf /dev/loop1 /mnt/dvdsafe
execve("/bin/mount", ["mount", "-t", "udf", "/dev/loop1", "/mnt/dvdsafe"], [/* 72 vars */]) = 0
uname({sys="Linux", node="cygnus", ...}) = 0
brk(0) = 0x805d000
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) <--- Huh? Indeed not there, but?
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=77944, ...}) = 0
mmap2(NULL, 77944, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40000000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\211"..., 512) = 512
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
fstat64(3, {st_mode=S_IFREG|0755, st_size=1174184, ...}) = 0
mmap2(0x49b73000, 1101412, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x49b73000
mmap2(0x49c7a000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x106) = 0x49c7a000
mmap2(0x49c7e000, 7780, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x49c7e000
close(3) = 0
munmap(0x40000000, 77944) = 0
open("/dev/urandom", O_RDONLY) = 3
read(3, "\304\227\202?", 4) = 4
close(3) = 0
brk(0) = 0x805d000
brk(0x807e000) = 0x807e000
brk(0) = 0x807e000
umask(033) = 022
open("/dev/null", O_RDWR|O_LARGEFILE) = 3
close(3) = 0
getuid32() = 0
geteuid32() = 0
lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=562, ...}) = 0
stat64("/sbin/mount.udf", 0xbffff110) = -1 ENOENT (No such file or directory) <--- WTF? udftools-1.0.0b is installed...
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV], NULL, = 0
mount("/dev/loop1", "/mnt/dvdsafe", "udf", 0xc0ed0000, 0) = -1 EINVAL (Invalid argument)
rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV], NULL, = 0
write(2, "mount: wrong fs type, bad option"..., 104mount: wrong fs type, bad option, bad superblock on /dev/loop1,
or too many mounted file systems
) = 104
stat64("/dev/loop1", {st_mode=S_IFBLK|0600, st_rdev=makedev(1, 1), ...}) = 0
open("/dev/loop1", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 3
ioctl(3, BLKGETSIZE, 0xbffff240) = 0
close(3) = 0
exit_group(32) = ?
#

[stonent]

I thought all loop systems needed -o loop on them...
Such as

Code: Select all

mount -o loop blah blah blah

[saccory]

FYI cryptoloop is kind of DEPRECIATED in favour of dm-crypt. See http://www.saout.de/misc/dm-crypt/ for details.
And btw. dm-crypt works great here

[TheCoop]

ditto, got a 256MB dm-crypt partition on my laptop I store all my important stuff on, works perfectly

[genneth]

I would recommend googling for encfs and fuse. These are userland thingys and does not need root access.

[Quantumstate]

OK, thanks.

Stonent, mine is the technique given in the (older) crypto loopback HowTo, which worked fine in Mandrake. Now with Gt it seems to miss mount.udf, for some reason.

Saccory, I'll study dm-crypt, and Genneth encfs & fuse. Any idea whether any of these'll read loop-created volumes? I need to recover the data.

[Quantumstate]

Am forced to abandon loop-AES and other methods except dm-crypt, as I'm way behind schedule. It does seem that dm-crypt has a chance of reading my older encrypted disks.

In accord with the HowTo, have recompiled =gentoo-dev-sources-2.6.5-r1 with
CONFIG_CRYPTO_AES=y

CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y

CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_COMPRESSLOOP=m
and rebooted to it.

Then emerged device-mapper and installed cryptsetup.

And did
# losetup -e aes-256 /dev/loop1 /dev/sr1
# cryptsetup status /dev/sr1 /dev/loop1
... but get ...
Command failed: invalid argument

Also, can't see how to use cryptsetup to mount an existing dvdram. Maybe my backups are lost; compatibility problem, exactly as I feared when I made them. I have to go throw up now.

[saccory]

Any idea whether any of these'll read loop-created volumes? I need to recover the data.

Dm-crypt is supposed to support cryptoloop devices/files. But some versions of cryptoloop/losetup were quite broken. I used cryptoloop too and I didn't succeed in converting all my data, yet. More infos: Cryptoloop Migration Guide

[Quantumstate]

Thanks for helping Saccory.

After some research I find that Mandrake uses loop-AES (one, of three possibilities). I used the link you provided to build util-linux after applying by hand, his patch and all the standard Gt patches in the ebuild. No dice.

Looks like I'm out of luck and time. I'll just attempt to proceed with dm_crypt, and never allow lost backups to happen again. I encrypted them in the first place because a set was stolen, but I guess this is what I get for having something worth stealing.

[saccory]

As far as I understand, the only problem is to recover the key used for the encryption (aes still is aes, no matter what program uses it). I've a lot of cryptoloop/losetup encrypted dvds and I can read them very well with dm-crypt. I just have to use the -h plain option with cryptsetup.
E.g

Code: Select all

losetup /dev/loop1 /dev/cdroms/cdrom0
cat keyfile | cryptsetup -h plain create cryptdvd /dev/loop1
mount /dev/mapper/cryptdvd /mnt/cryptdvd/

[IvanHoe]

FYI cryptoloop is kind of DEPRECIATED in favour of dm-crypt. See http://www.saout.de/misc/dm-crypt/ for details.
And btw. dm-crypt works great here

Where is cryptoloop deprecated? I'm using kernel 2.6.7 and cryptoloop is part of it (not dm-crypt) and nowhere does it say that it's deprecated.

[saccory]

Please see Linux: Replacing Cryptoloop With 'dm-crypt'

and from
http://www.tldp.org/HOWTO/Cryptoloop-HO ... ction.html

IMPORTANT: Cryptoloop has been marked deprecated in the latest 2.6 kernel. This means that it will no longer be maintained actively. The successor to Cryptoloop will be dm-crypt. Dm-crypt is available in the main kernel since 2.6.4. Cryptoloop will still be available in the main kernel for a long time, but dm-crypt will be the method of choice for disk encryption in the future. Dm-crypt is based on the device mapper and offers pretty much the same functionality as Cryptoloop. It is still very new and there are no easy-to-use userspace tools available yet. Dm-crypt is considered to be much cleaner code than Cryptoloop, but there are some important differences. For example, creating an ecrypted filesystem within a file will still require to go through a loop device, but this support is still in development.

[IvanHoe]

Alright, I found dm-crypt, it was under "Multi-device support". Cool, hopefully it's compatible with cryptoloop.

[Quantumstate]

Where is cryptoloop deprecated? I'm using kernel 2.6.7 and cryptoloop is part of it (not dm-crypt) and nowhere does it say that it's deprecated.

Also, "dm-crypt is vastly superior to cryptoloop for a number of reasons:
1) It does not suffer from loop.c bugs (There are a lot, no maintainer)
2) dm-crypt does not depend on special user space tool (util-linux)
3) dm-crypt uses mempool, which makes it rock stable compared to {sic} cryptoloop."


After much work and research I find that Gentoo 2.6.5 will write DVDRAMs with no further patches nor modification! I was diverted from this because all writings are to the contrary, in kernel Documentation, and HowTos (packet) in these forums. To be clear, =gentoo-dev-sources-2.6.5-r1 will allow you to read and write DVDRAM disks just like a harddisk (albeit muuch slower), as long as you enable UDF (whether as a module or compiled in). Simply mount /dev/srn.

Now, on to dm-crypt.

Saccory, I have the kernel compiled properly, and get the /dev/mapper/control device node automatically. Also support apps are installed (hashalot, libgcrypt, device-mapper{/usr/lib/libdevmapper.a, dmsetup}, cryptsetup). Using your commands above however, on
cat keyfile | cryptsetup -h plain create cryptdvd /dev/loop1
it's unable to find 'keyfile'. Seems like this file should be in the current directory, and should be piped through the device? Or is it to be retrieved from the device?

Also, losetup does not ask for a password, I presume because we are not specifying -e aes-256? And it seems that 'create' does not erase the disk, but just sets up the device chain?

I tried:
cryptsetup -h plain create cryptdvd /dev/loop1
{it asked for the password, and was happy}
mount /dev/mapper/cryptdvd /mnt/dvdsafe
mount: wrong fs type, bad option, bad superblock on /dev/sr1,
or too many mounted file systems

So, from the HowTo I tried:
cryptsetup -c aes -y create secret /dev/loop1
{it asked for the password, twice, and was happy}
mount /dev/mapper/secret /mnt/dvdsafe
mount: wrong fs type, bad option, bad superblock on /dev/sr1,
or too many mounted file systems


I now remember that I'd created these disks on kernel 2.4.25 (Mandrake), specifying AES 256. My mount script then, was:
losetup -e AES256 /dev/loop1 /dev/sr1
mount -t udf /dev/loop1 /mnt/dvdsafe
which worked well.

BTW, your English is flawless.
(Although Uma and Laura Croft seem scarey)

Grusse

[linux_girl]

i am missing something :

ichanged the ower of /dev/loop0 (symlink) then the ower of /dev/loop/0

i added to fstab

Code: Select all

#/etc/fstab
/dev/loop0     /home/pbx06/secmount           user,noauto     0 0

then as a regular user i rune the script :

Code: Select all

#!/bin/sh
/sbin/losetup -e aes-256 /dev/loop0 ~/sec.file
mount -t ext2 /dev/loop0 ~/sec

but i get :

Code: Select all

memlock: Operation not permitted
Couldn't lock into memory, exiting.
mount: only root can do that

since i changed /etc/fstab . i should not get the mount error right ?


may be a C prog that do the same thing as the script do. but with setuid root should do the trick ?
or maybe a setuid root on losetup

[saccory]

Using your commands above however, on
cat keyfile | cryptsetup -h plain create cryptdvd /dev/loop1
it's unable to find 'keyfile'.

Keyfile is the file where I keep my key If you type in yours, you just leave out the cat command and cryptsetup should ask for the passphrase. But I see, that you already tried that and it didn't work either I have no idea what's different from my setup.

Also, losetup does not ask for a password, I presume because we are not specifying -e aes-256? And it seems that 'create' does not erase the disk, but just sets up the device chain?

That is right. Cryptsetup does only create/remove mappings. Which also means, that if you want to create a new encryption container you have to run a mkfs on your /dev/mapper/xxx mapping.