Mailinglist Archive: opensuse (3831 mails)

< Previous Next >
Re: [opensuse] encrypted usb drives - fixed mount points
  • From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
  • Date: Thu, 18 Jan 2007 14:36:22 +0100 (CET)
  • Message-id: <Pine.LNX.4.64.0701181211290.16241@xxxxxxxxxxxxxxxx>
Hash: SHA1

The Wednesday 2007-01-17 at 21:54 -0500, Dennis E. Slice wrote:

> [Sorry for the formatting. I wanted to reorder the comments.]

No problem, I do that sometimes.

> My system works fine, but I was very interested in Carlos' suggestions.
> Here are my observations:
> > They would mount if available at boot time, if the service is enabled:
> >
> > nimrodel:~ # chkconfig boot.crypto
> > boot.crypto on
> >
> > and the device is available at that time. It prompts for a password during
> > boot up.
> boot.crypto tries, but fails to find the partitions at boot time. In
> fact, it fails without delay.

Not very surprising in your case, as it is an USB device, so it is not

> > As I mentioned previously, you can also use fstab for encrypted
> > partitions. For instance, one of mine:
> >
> > /device_or_file /mnt/crypto xfs noauto,loop=/dev/loop4,encryption=twofish256 0 0
> >
> >
> > I doubt labels could be used here, but I assume dev-ids would - I never
> > thought of that till reading this thread ;-)
> Right, there is no way to label an encrypted partition as far as I can
> tell. I moved the specs to fstab, but no go. At boot, the system doesn't
> seem to know about encryption and just says:
> mount: going to use the loop device /dev/loop0
> /dev/disk/by-id/usb-WD_<snip>-part1: No such file or directory
> mount: failed setting up loop device

Maybe because usb is not setup yet.

> for each drive. Here, the drive lights are not yet on.
> Subsequently, trying to manually mount the partitions as root gives:
> ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key
> length (256 bits) not supported by kernel

Mmm, that's funny!

> I am curious as to why the initial boot.crypto fails,

I believe because usb is not fully up, or if not, the partitions IDs have
not appeared yet. I can not test it.

> why booting with
> the specs in fstab doesn't invoke boot.crypto,

No, that's by design. The fstab way is a different way: choose one or the
other for each device (I have one method of one device, and the other for

> and why my kernel doesn't
> support 256 bit encryptions.

Well, that's "funny", and I don't understand it. If your encrypted
partition can be mounted manually using boot.crypto, it must work via
fstab as well.

> Actually, I guess I just didn't specify
> something about the latter when I installed, but I'm not going to
> reinstall the kernel at this time - everything does work as originally
> described.

I don't think so. The twofish256 method is the one used by Yast, so SuSE
kernels support it by default. It has to be something else.

Hold on, you are using 10.0 and I am on 10.1... no, it shouldn't be that.
I know there were big changes in 9.x, but not in 10.0

I'm not sure...

Anyway, if you are using the encryption method that Yast uses when
creating encrypted partitions, you should have no problems.

Maybe your fstab line is incorrect. Let me see, in cryptotab you have
(from a previous post):

/dev/loop0 /dev/disk/by-id/usb-WD_<snip>-part1 /media/USB320_0 reiserfs twofish256 acl,user_xattr
/dev/loop1 /dev/disk/by-id/usb-WD_<snip>-part1 /media/USB320_1 reiserfs twofish256 acl,user_xattr

Then your fstab lines would be:

/dev/disk/by-id/usb-WD_<snip>-part1 /media/USB320_0 reiserfs noauto,loop=/dev/loop0,encryption=twofish256,acl,user_xattr 0 0
/dev/disk/by-id/usb-WD_<snip>-part1 /media/USB320_1 reiserfs noauto,loop=/dev/loop1,encryption=twofish256,acl,user_xattr 0 0

You see, the lines are very similar to the cryptotab file, but in a
different order. They have the "noauto" option so that boot doesn't try to
mount them. Also, the fsck digit is "0" so that it doesn't try to run fsck
on them; even "thinking" about it and not finding the disk will make the
boot.localfs stop while booting and request you run a manual fsck. Quite

> > sync/nosync?
> >
> Not sure the relevance here for encrypted partitions. I am running with
> whatever the default is and previous discussions seemed tp focus on
> FAT32 files systems and such.

It does have relevance for other partition types, but I'm not sure about
encrypted ones.

By the way, when an encrypted partition fails to mount, the messages it
gives are confusing. Looking at the output of dmesg may help.

I'll write here my procedure for testing. I use xfs partitions, so don't
take the commands literally. Also, I'm using a file instead of a
partition, so there are some differences.

* Creation procedure (equivalent to what yast does):

For files, first you need to create an empty file:

dd if=/dev/zero of=crypta.bck bs=1MB count=4700

(note: 1MB = 1e6 bytes; 1MiB = 2^20 bytes)

The peculiar size is for later burning dvds. For partitions, you simply
create the partition (fdisk). Then, you activate the loop device on it,
choosing the encryption type:

losetup -T -e twofish256 /dev/loop1 crypta.bck

The "-T" is to make it ask for the password twice (crucial when creating!
;-) ). There are many encryption methods, and I don't fully understand
them, but "twofish256" is what Yast is using in SuSE 10.1.

Then, you format or create a filesystem:

mkfs -V -t xfs -L CryptoBackup /dev/loop1


mkfs -t ext3 /dev/loop1

as you wish. Or reiserfs, or whatever.

Finally, "losetup -d /dev/loop1" will detach the loop device. The "-a"
will show what is attached.

* manual mount - easier to see where the problem is:

losetup -e twofish256 /dev/loop1 crypta.bck
mount -t xfs /dev/loop1 /mnt/tmp


umount /dev/loop1
losetup -d /dev/loop1
losetup -a

* running a fsck:

losetup -T -e twofish256 /dev/loop1 crypta.bck
fsck /dev/loop1

because fsck is run before mounting a device.

* backup to dvd:

Burn the umounted crypta.bck file to dvd as an image (not iso!), via
the preferred method. I use:

growisofs -dvd-compat -Z /dev/hdc=crypta.bck

Actually, I have a little script that checks the file is not mounted,
burns, and finally compares the result.

Those are my notes... I hope not to have mistyped things. O:-)

- --
Carlos E. R.

Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76


To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups