Richard (MQ) wrote:

Looks like the crypto modules aren't loaded - try (as root of course)

# modprobe twofish # modprobe cryptoloop

and then re-try your mount.

I should have thought of that, but it doesn't work: minas-morgul:~ # mount /mnt/dvd.crypta.x Password: mount: you must specify the filesystem type There is no message in the kernel log, which I have just activated. My fstab has: /dev/dvd /mnt/dvd.crypta.x auto \ ro,noauto,user,loop,encryption=twofish256 0 0 and it worked in 10.2. I'll try specifying the fs, which is XFS. [...] It fails again: minas-morgul:~ # mount /mnt/dvd.crypta.x Password: mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so The kernel log says: Sep 23 15:26:15 minas-morgul kernel: SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled Sep 23 15:26:15 minas-morgul kernel: SGI XFS Quota Management subsystem Sep 23 15:26:17 minas-morgul kernel: XFS: bad magic number Sep 23 15:26:17 minas-morgul kernel: XFS: SB validate failed /var/log/kernel lines 1-5/5 (END) No good :-( I think it ignores the loopback. -- Cheers, Carlos E. R. (from RC1) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Juan Erbes wrote:

2007/9/23, Carlos E. R. <>:

...

Hi,

I have the following defined on 10.2 (works fine):

/dev/dvd /mnt/dvd.crypta.x auto \ ro,noauto,user,loop,encryption=twofish256 0 0

You must set this in the udev rules, because the removable devices are now managed by the udev rules, and the permissions by Policikit. The settings for removable devices in fstab make no sense. The only removable device that continues appearing in fstab is the floppy.

Could you please expand on this, giving exact instructions? Remember that it works in 10.2 perfectly. Has udev changed in 10.3 so much? There is no comment about this in the release notes. Can't DVDs be mounted manually, then? I don't believe it. This is something solely related to encryption changes, not udev. Proof: I mounted my external USB drive manually via fstab. No problem at all: LABEL=usb_sg60 /mnt/usb/usb_sg60 reiserfs \ noatime,user,noauto,acl,user_xattr 0 0 -- Cheers, Carlos E. R. (from RC1) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rajko M. wrote:

It can be mounted manually, but if you can configure udev rules to do that for you why not to use them. Reduction of typing is the primary reason for existence of fstab, modprobe.conf, etc. Problem with udev is that it is new and not really explained on openSUSE example.

Why should I? Remember, this is an encrypted DVD we are talking about. It has to be mounted manually because: a) udev can not know it is encrypted, nor how it is encrypted. b) I have to type the password. The problem now is that mount fails in 10.3 and not in 10.2. That is the problem at hand. -- Cheers, Carlos E. R. (from RC1) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Richard (MQ) wrote:

...

The problem now is that mount fails in 10.3 and not in 10.2. That is the problem at hand.

I'll leave the udev stuff to those who understand it - meanwhile:

Thanks :-)

1. Symptoms are of mismatched data / password (modules are loaded now!)

Do you have the md5 sum or similar for the encrypted file (see below)? It may be corrupt / dirty. Try cleaning & re-inserting?

I have dozens of those encrypted dvds, I can try another. That one in particular I read from 10.2 without problems a week ago. [...] Ok... it works. All of them. It was my fault. Between two of the tests I forgot I had replaced the encrypted dvd with the 10.3 dvd. The problem were the kernel modules. I had to reboot due to a kernel update this morning, and after that I went right away to this thing, and forgot to exchange the dvd. Ough.

2. Try manually mounting. As root, something like:

mkdir /mnt/dvd mount /dev/dvd /mnt/dvd (maybe needs -t iso9660 -o ro as well?) losetup -e twofish256 /dev/loop0 /mnt/dvd (or /mnt/filename ?) mount -o ro -t xfs /dev/loop0 /mnt/dvd.crypta.x

Yes, good idea. I have done that other times and it helps a lot in determining the problem. It just didn't occur to me this time. I must be tired. Mine are not iso images, but xfs images, burnt directly.

I use encrypted CDs and DVDs too, usually I generate a random file and loop-mount it, & save an accompanying md5 to check if it refuses a mount. Usually it's because it's scratched or dirty, or I have the wrong password.

I don't follow this part :-? -- Cheers, Carlos E. R. (from RC1) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sunday 23 September 2007 20:06:01 Richard (MQ) wrote:

...

I don't follow this part :-?

Getting a bit OT but:

But very interesting, for us and somebody else wanting to do encrypted backups. Ah! Before I forget: I wrote to '/etc/sysconfig/kernel' this line: MODULES_LOADED_ON_BOOT="cryptoloop twofish" I think this should work to load those two modules instead of using boot.local

I create a regular file of rubbish, and loop-mount it with crypto before generating a filesystem and finally mounting normally:

$ dd if=/dev/urandom of=file.img count=700 bs=1048576 (i.e. owner=user)

/dev/urandom, /dev/random... what's the difference? ... (un)signed, perhaps?

# losetup -e twofish256 /dev/loop0 file.img # mkfs.ext3 /dev/loop0 # mount -t ext3 -o rw /dev/loop0 mountpoint

Copy what I want to keep to mountpoint then:

# umount mountpoint # losetup -d /dev/loop0

$ md5sum file.img > file.md5 (i.e. owner=user again)

Then write file.img and file.md5 to cd using k3b. Easy to test integrity without having to crypto-mount:

$ cd cd-mountpoint $ md5sum -c file.md5

Curious!

And to mount for reading

# losetup -e twofish256 /dev/loop0 cd-mountpoint/file.img # mount -t ext3 -o ro /dev/loop0 mountpoint

Not too hard to script these steps, except for the problem with cd mount-point names under /media. Of course, same idea for DVDs.

I always mount manually, so I don't have the /media names problem. My procedure is simpler. First I create an empty file: nimrodel:~ # nice dd if=/dev/zero of=crypta_f_dvd \ bs=1MB count=4700 4700+0 records in 4700+0 records out 4700000000 bytes (4.7 GB) copied, 99.32 s, 47.3 MB/s (Watch line wrap: I'm using kmail now and i don't know how to tell it not to wrap) I didn't think to randomize it, as I suppose the encryption thing will do its work. The file has the exact size of a DVD image. Then I encrypt it via loop: nimrodel:~ # losetup -T -e twofish256 /dev/loop2 crypta_f_dvd Password: Retype password: nimrodel:~ # file -s /dev/loop2 /dev/loop2: data And I create the XFS filesystem on the loop device: nimrodel:~ # mkfs -V -t xfs -L CryptoDVD_MM /dev/loop2 nimrodel:~ # file -s /dev/loop2 /dev/loop2: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) And that's all. I can mount that filesystem via fstab (after the losetup thing is freed): /imgs/crypta_f_dvd /mnt/crypta.x.dvd xfs \ noauto,user,loop,encryption=twofish256 0 0 In this way, I can simply copy the files I want to backup to the mounted image in /mnt/crypta.x.dvd just using any tool I want. When done, I umount it, then burn the image directly using growisofs or k3b. I can test the dvd: minas-morgul:~ # losetup -e twofish256 /dev/loop2 /dev/hdc Password: minas-morgul:~ # file -s /dev/loop2 /dev/loop2: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) This is the step I should have done this morning, by the way.

I generally use this scheme for backups of documents, emails etc. - not spectacularly secret, but potentially useful to an ID thief. Most ordinary punters won't be able to read it, but of course GCHQ / NSA etc. wouldn't take very long if they ever wanted to...

Of course :-)

A lot of people take essentially no backups, and many of those who do take them leave unprotected data lying around. Not very sensible really!

True... I don't encrypt every thing. My filesystem is plain, but there are somethings I keep encrypted. I have been bitten with a corrupted filesystem just while I was adding a new HD to make fast backups - Murphys law :-( The problem nowdays is that DVDs are too small for making backups of a 300 GiB HD :-( -- Cheers, Carlos E.R. (from RC1) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-09-24 at 08:19 +0100, richard (MQ) wrote:

Carlos E. R. wrote:

...

Ah! Before I forget: I wrote to '/etc/sysconfig/kernel' this line:

MODULES_LOADED_ON_BOOT="cryptoloop twofish"

I think this should work to load those two modules instead of using boot.local

It will, but it will be over-written on upgrade. The point about /etc/boot.local is that it is (supposed to be!) protected when upgrading (and is also easy to backup / restore manually). Same applies to a number of other files with similar names (I think this is specific to OpenSuSE ?)

Mmmm... If it is overwritten on upgrade, it is a bug and should be reported. Files in that directory are parsed. For instance, I ended with an almost broken /etc/sysconfig/SuSEfirewall2 after several cascaded upgrades; I had to locate the original file, copy it over, and add my changes with and editor. I still have to do the same for the cups config file, there have been chages which didn't apply. Yes, there are a number of files in /etc/init.d that belong to the user and are not replaced. At most, they would be moved to file.rpmold or somthing like that. To keep slightly on topic for this list, I was scared/confused by the comentary on encription changes appearing in the release notes of RC1. (The rest of this email is probably OT for this list)

...

My procedure is simpler. First I create an empty file:

nimrodel:~ # nice dd if=/dev/zero of=crypta_f_dvd \ bs=1MB count=4700 ...

...

I didn't think to randomize it, as I suppose the encryption thing will do its work. The file has the exact size of a DVD image. Then I encrypt it via loop:

As a general principle, you should use a fresh (different) random set for each such encrypted file / disc, so that an attacker has less to go on when trying to crack it (e.g. by comparing encrypted files & looking for correlations). The extra security is probably rather irrelevant here...

However, I suppose that when creating the filesystem on top, and after the encription, almost every original byte will be overwritten. Or that's what I thought, at least. Those that are untouched contains no data of the present backup and are irrelevant. Maybe in my case they contain data from the previous backup. Well, to be really secure, you have to keep a very long key in another media, like a memory card. To get back the data, you need then the encrypted data, the usb key, and the password: they need to stole both and force the password out of you, which is quite difficult to happen for a normal thief. However, I'm unsure how to create those beasties. Documentation seems to be scarce and written for crackers.

...

And I create the XFS filesystem on the loop device:

Just out of interest - why XFS?

Heh! :-) Good question. Well, I choosed it because it has the lowest directory and fixed structure reserved ahead of time. Less reserved sectors, more space for your data. I think they are reserved and created as you write your files. Reiserfs, for instance, is the worst in this respect: so much so that the utilities usually refuse to prepare a reiserfs smaller than 100 MB. Ext2 is good, but ext3 has to keep a journal somewhere (xfs too, I think). Difficult to create a plain ext2 without journal by mistake: I tried. I did some measurements storing some quite large files and it came out that xfs had the biggest free space left, so that I could store 12 of my data sets instead of 11, meaning less DVDs were needed. The snag is that I can not mount simultaneously one of those DVDs and the backup image: it appears XFS has some kind of ID, and it refuses to mount because there is already one XFS filesystem with that ID mounted. And I do not know what will happen the day I get a scratch on a DVD: will it be mountable? O repairable?

...

The problem nowdays is that DVDs are too small for making backups of a 300 GiB HD :-(

Quite so. Even HD DVDs (when they finally become mainstream) are tiny in comparison.

Yes... my normal backups go to an usb HD enclosure now. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFG95DqtTMYHG2NR9URAiPWAJ4jwW6lOxsYjpG23XIkNkNV+EagHQCdEEUi 6Y0V3OFxQjEBKXGhDtd4Uo8= =8RDr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-09-23 at 20:21 -0300, Juan Erbes wrote:

You can continue to mount by hand.

Good, you scared the life out of me! ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFG9wy1tTMYHG2NR9URAhnSAKCRwzCBjDUH7Rk3GJ773n6ywKdsVACeNCLS 8Z/N+4Zq1mejnHV8hCqWxmw= =EPuq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org