# unable to mount old encrypted DVD

## JeroenV

Hi,

A year ago, before the cryptoloop system apparently universally changed, I created an encrypted DVD with cryptoloop, blowfish-256 with a password shorter than 20 characters.

Since I upgraded to the new loop-aes system, I cannot mount my old DVD anymore:

```

~ # losetup -e blowfish-256 -H unhashed2 /dev/loop1 /dev/cdrw

Password:

WARNING - Please use longer password (20 or more characters)

ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length (256 bits) not supported by kernel

```

I tried some variations for the -e and -H options, but none worked.

I also checked whether the blowfish kernel module was loaded; it was. Although I seem to remember that in the old situation the module was called blowfish-256 or something like that.

```

~ # cat /proc/crypto

name         : blowfish

module       : blowfish

type         : cipher

blocksize    : 8

min keysize  : 4

max keysize  : 56

```

Seems the key-size is now in bytes? (or very short) But anyway, even in this case 256bits is in the range?

Any ideas how to solve this? (preferably without reverting to the old kernel, and old losetup or whatever...)

TIA

----------

## bhun

Hi Jeroen,

Just guessing, but shouldn't you use blowfish without the -256 suffix to setup the loopback device?

```

~ # losetup -e blowfish-256 -H unhashed2 /dev/loop1 /dev/cdrw

```

Last edited by bhun on Sat Apr 08, 2006 1:20 pm; edited 1 time in total

----------

## JeroenV

I tried that too, it just gives me the message that the kernel doesn't support 128 bit keys (instead of the previous 256)

----------

## bhun

 *JeroenV wrote:*   

> I tried that too, it just gives me the message that the kernel doesn't support 128 bit keys (instead of the previous 256)

 

What you describe seems to be the default action if the crypto api does not match one of the supported api's (see mount/loop.c in the source code). The only way I can get the exact problem (being unable to mount the previously mountable now not-mountable encrypted disk), is by remerging with "USE=-crypt". The loopback gets set up, but the mount fails. When I remerge with "crypt" support, everything works again. Well, no luck then. Have fun.

----------

## JeroenV

I just added old-crypt to my USE flags and remerged util-linux.

That way it makes a binary called losetup-old-crypt, that probably is supposed to work like it did before the api-change. 

Still no luck, though:

```

# losetup-old-crypt -e blowfish-256 /dev/loop1 /dev/hdd

Password:

ioctl: LOOP_SET_STATUS: Invalid argument

```

Might it have to do with incompatibility of the blowfish kernel module?

(i.e.: with the old system I recall cryptoloop was included in the kernel)

----------

## bhun

 *Quote:*   

> 
> 
> Might it have to do with incompatibility of the blowfish kernel module?
> 
> 

 

I have no idea, the same kernel module was used to create an encrypted loopback device (i have no p0rn to encrypt  :Smile: ) and tried to figure out what you did. You're probably right.  :Smile: 

Well, good luck then. Maybe somebody else can help you out, I hope you manage to get it right.

----------

## Celegans

I encountered the same problem.  This is how I resolved it:

emerge =sys-apps/util-linux-2.12i-r1

...this will bring back a version of losetup that can access the existing volume.

I used it to losetup, then mount the volume, as I usually did.  

I then re-emerged util-linux (latest & greatest)

Using the latest and greatest losetup, I created a new encrypted volume (with a >20 char password),

then copied the contents from the original volume to the new one.

Once verified, I blew away the old volume.

...note that this was fairly straight-forward for me, as I was working on LVM volumes.

Hope this helps.

Cheers.

----------

## JeroenV

Thanks,

I figured that would be a way, but I was reluctant to downgrade because in my case it's DVD's, so I'd have to re-backup the data.

Anyway, I'll try the method and copy the losetup binary over somewhere. I'll post the results (may take two days due to time constraints).

BTW, I was hoping that the old-crypt useflag would just give me exactly that losetup binary you describe, but as shown above it didn't work...

----------

