I’m running Fedora 32. I have several backup disks which have all been encrypted with cryptsetup and were working fine until a few days ago. Now when I do cryptsetup luksOpen path-to-device name
I get an error that the key is invalid.
No key available with this passphrase.
This happens on all of my backup drives. They’re all different physical drives in separate enclosures. The only commonality is they use serpent-cbc-plain for the cipher. I also tried booting the last kernels in the grub list but cryptsetup luksOpen fails the same way.
When I boot the rescue image I get a message that the cipher isn’t available, I guess the kernel module is not in the rescue image. So I am not able to verify that it is related to kernel level or app level.
I did create a new luks file with the same cipher and hash and I am able to open and close it several times. It suggests some component was updated and broke access to older files.
Any help guys? I have around 3T of data offline now. Thank you. Bill
Have you alredy tried to downgrade cryptsetup? Was there a cryptsetup update “a few days ago” as you mention or do you suspect any other updated package to break cryptsetup?
Thank you, I just tried this. I am still getting the same error message.
I wonder if newer kernels changed the code for the serpent cipher. I don’t know what to suspect. I usually take a quick look at updates and accept them all. I do
Thanks! Ok, this works. Data is fine. What should I do now? How can I identify the differences that could cause the problem, since the Live disc works like Fedora did until a few days ago?
Thank you. I’ll compare them, can’t boot the live image right now. One thing I noticed is that some ciphers like blowfish, twofish have both _common and _generic.ko.xz modules but serpent only has _generic. I don’t know if this means something is missing or that the _common is not needed.
Checking dnf provides, I see it serpent is only in the kernel package and back to 5.6.6-300 there is no serpent_common listed.
Yes, the installed F32 does show serpent-cbc in the cryptsetup benchmarks.
That is a good question. I am not familiar, so I am afraid I can’t be of much help here. If this was my machine, I would file a bug (against cryptsetup) since this is a serious regression. Something that works with the live image is supposed to be supported throughout the entire life cycle of a Fedora release.
Interestingly, when I specify the --cipher or -c it doesn’t help.
I changed it to -c dummy-abc-plain and the outcome is the same. I would expect to get an invalid cipher message but it still gives me the no key available with this passphrase message.
I’ll look into filing a bug but I’m not hopeful that I’ll be able to give enough doc to answer their questions.
By the way, I would hope this would be valid forever, some of these containers are many years old. I expect luks to be upward compatible or that would be a disaster for anybody who relied on it for archiving.
It doesn’t produce anything useful, command failed with code -1 (wrong or missing parameters).
When I have time I’ll create a luks container using the live image and maybe it will fail to open on the installed system.
Fedora Packages has been down since I read your post about filing a bug. I want to try to check for anything related but getting 503 Service Unavailable. Maybe that page depends on luks
This one is broken since two years, two alternative web apps have been developed, sadly none has been deployed. What is the information you were trying to look up on the Packages app? We can help you find it elsewhere…
