luksOpen doesn't decrypt with keyfile unless --key-file argument is provided

Question

I have an encrypted volume for which I had initially set up a passphrase interactively, which works just fine to decrypt the partition. I added more keys using a keyfile in both the following ways:

cryptsetup --keyfile=passphrase luksAddKey /dev/sdax
cryptsetup --luksAddKey /dev/sdax passphrase

where passphrase is the file containing the key and /dev/sdax is the encrypted volume.

I then checked if the passphrase was valid using

cat passphrase | cryptsetup --test-passphrase luksOpen /dev/sdax
dd if=passphrase bs=1 count=256 | cryptsetup --test-passphrase luksOpen /dev/sdax

but both of them failed: "No key available with this passphrase." The following command using the --key-file option worked:

cryptsetup --test-passphrase --key-file passphrase luksOpen /dev/sdax 

At this point I tried to see if the method of piping the passphrase content worked with the only working passphrase (set up interactively).

echo "manually written working passphrase" > interactive_pass
cat interactive_pass | cryptsetup luksAddKey /dev/sdax

This time it worked just fine. What is the difference between the two methods and the two key files? I would need the first method of piping the file content to work also with passphrases added from key files, since it seems the only possible method when using a script in crypttab. Is it possible?

Answer 1

This is explained in detail in the cryptsetup man page on NOTES ON PASSPHRASE PROCESSING FOR LUKS. There are differences such as including newlines or not, different size limits (e.g. 512 bytes for interactive passphrases, check cryptsetup --help), ...

If you want to avoid this particular piece of hassle, it is best to create keyfiles that also work when typing them on the terminal into the interactive cryptsetup prompt. This means the keyfile must be a plain text string and must NOT include a newline character at the end. (Use echo -n or printf "%s".)

For example you could use pwgen to generate a 64 character password keyfile.txt that can also be typed manually in an emergency:

$ echo -n $(pwgen 64 1) | tee keyfile.txt
Aish6shaejongi9yug3quij7aijop7SieTh7ierahngaem8iov5isho5dae0pisu

With a keyfile such as this there should be no difference in interpretation regardless how you pass it to cryptsetup. The exception is using the wrong keyboard layout when typing it. If you expect keyboard layout problems, you could add the passphrase twice so LUKS will accept either one.

This is particularly important when using /dev/urandom keyfiles... if you use them the wrong way, it might have stopped processing early on (a random newline character appears) and your password is a lot shorter than you believe it to be.

Answer 2

When you pass the passphrase on standard input, cryptsetup reads one line of input, and discards the newline at the end of this line as well as any subsequent line.

When you pass the passphrase from a file with --key-file, the full contents of the file are used. If the file contains a newline then the passphrase cannot be identical with one that is passed on standard input.

Answer 3

You need to use the -h option. The passphrase is first hashed before using it as a key-file; that is how you get from a few characters to 256 or 512 bits. So depending what options you used for luksFormat and how you plan to unlock it, you need to specify e.g. -h plain or some other parameter.