Many years ago I created an encrypted file to store some very personal stuff I didn't want to be accessible to anyone: at that time I was running slackware-1x on a 32 bit laptop with no disk encryption. A few years later, with slackware-14.x I moved to x86_64 and I started encrypting my whole disk, so I opened that old file and transferred its content (all of it?) to my file system.

Today I was cleaning up my home directory and, finding that old file still sitting there, I thought to open it to check if everything was actually saved. To open it I used to use these commands:

(crypto.serpent is the file... I named it so to remember the cipher)

Now, losetup -e has gone but, if I'm reading the documentation correctly, cryptsetup should be backward compatible, and so something like this should do the job:

The problem is that I'm now getting:

Now, serpent support, in slackware, should be built into the kernel so I do not know what I'm missing.

As I said, I do not think I'm facing a data loss problem, but I'm puzzled because when I created that file I thought I would not have problems accessing it in the (also far) future. Am I doing something wrong?

Best,
andrea

ps: obviously I remember the passphrase, and I know because I already opened it a few years after creating it.

Are you sure that the filesystem is ext2? If so, is ext2 compiled into the kernel or loaded as a module?

Indeed. I'd leave out the -t and let it figure it out. Also, I'd probably add -o ro for safety of the filesystem, at first.

You can run "file -sL /dev/mapper/mysecrets" to see if that file decrypted into something recognizable.

yes I'm sure, also because when I created the file I also created a short shell script to open it, in case I was going to forget how to do it...;-)

and yes, the ext2 module is indeed loaded.


thanks for the hint, which gives me some more info to work with. what I get is:

I'll do some more research...

thanks for your kind attention and help!

How big is that crypto.serpent file? It appears that you have merely decrypted a secret key file, not the file that holds your actual filesystem.

probably I did something wrong when getting the result I posted in my previous message... the file is 300M and I tried everything I could imagine and so I probably posted something which was the result of some wrong command I issued.

anyway, just to double check, I downloaded slackware-12 (32bit) and slackware64-14, installed them on a virtual machine with qemu and successfully decrypted my file on both of them (the file was created in 2005 and decrypted the last time in 2017). Everything was indeed saved on my file system... but, on the other side, I can confirm that, unless I'm missing something, cryptsetup is NOT backward compatible. which means that long term encryption in linux had not been not reliable -- which makes me think it won't be in the future. which is annoying because out there there are people relying on encryption to protect their freedoms and, sometimes, their lives: this should be something to be taken seriously.

I'd like to mark this thread as unsolvable, but I do not know how to do it and I still have a residual doubt that I may be missing something.

The only change I know of that might affect cryptsetup is one that bit me. I used the whirlpool hashing function with the serpent cipher on my encrypted backup hard drive with one of the 13.x versions (IIRC) of Slackware, but there was a flaw found in the implementation of the whirlpool hashing function and the fix in cryptsetup made the the new version of cryptsetup incompatible. I'm not sure if your encrypted image uses hashing or not, or whether you're using the whirlpool hash function, but if you are, that could be the incompatibility.

I had to use the old version of cryptsetup to replace the hashing function in the header with a more common one (I think I used SHA512) that the new version could work with and then use the new version to replace the more common one with the fixed whirlpool hash. I remember feeling a little panicky at the time.

2 members found this post helpful.

I'm pretty sure I did not use the whirlpool hash function but went with the plain default (probably, at the time, it was SHA-1)...

If you weren't using whirlpool, I'm out of ideas.

When you opened the encrypted file on the older versions of Slackware, did you use cryptsetup, or losetup? If cryptsetup, perhaps it is possible to figure out what changed in the intervening versions.

I used losetup with the cryptoloop kernel module... cryptoloop is still available in linux-5.15.x and, on slackware-15, installing util-linux-2.19 (the one I tried) it is still possible to use losetup to decrypt my file...

edit: even losetup from util-linux-2.21.2 (slackware-14.1) works.... the last one.

I wonder if VeraCrypt will open your file and mount it for you.

no it does not, and now I know why... sorry, my fault... apparently losetup, when creating an encrypted loop device with cryptoloop DID NOT use any hash function for the passphrase. dm-crypt and veracrypt require a hash function instead.

cryptsetup comes with the option to set the hash, but it also accepts "plain" for... no hash. and so:

does the job!

I apologize: dm-crypt is indeed backward compatible with cryptoloop.

I'm deeply sorry for the noise. (as an excuse I could say that "-h plain" is not documented in the man page and I think it is fair to say, as an option, it is counterintuitive).

2 members found this post helpful.

Good work! It's great to know that cryptsetup does work after all.

thank you for your precious hints that led me to the solution!