Something I stumbled upon today. I tried to unlock a LUKS container and was 100% certain that the passphrase is correct. Still, cryptsetup would not unlock the container:
# cryptsetup luksOpen /container_file container
Enter passphrase for /container_file:
No key available with this passphrase.
Digging around, references can be found to either a problem with the character encoding of the shell or to a bug with cryptsetup and Samsung EVO SSDs with certain older 5.1 kernels. None of these were the case.
After some trial and error, I upgraded the cryptsetup packages from 2:2.1.0-5+deb10u2 (from buster/main repo) to 2:2.3.5-1~bpo10+1 (buster-backports/main repo). Suddenly the container would unlock.
I think most of the time people either get their passphrase wrong or their header was corrupted somehow, but in this case: Some bug in cryptsetup. (Not reported yet, no existing report found yet.)
I have the same issue on Arch Linux! I made sure it wasn’t an encoding issue or input issue – even keyfiles are recognized by old versions of cryptsetup but not the latest. Unfortunately it’s keeping me from booting normally but hopefully an upstream update will fix it.