In cryptography there is a important difference in a binary cryptographic key and a user input passphrase (which is hashed to generate the key). The man page for cryptsetup is not however very clear on this difference and its relevance in the appropriate options. Probably best to use one method and not the other.
However as you are using LUKS form of encryption (the input passphrase or key, is only used to decode the actual cryptographic key stored in table) then it more likely that a keyfile and a passphrase are the same thing.
However it clear in the man page is that when a keyfile is used return characters will be treated as part of the input (or passphrase). On the other hand passphrase input will stop when a return character is given.
This in and of itself will be enough to make what you are doing fail, especially as most editors will ensure that the last line of any text file has a final newline!
Basically a 'keyfile' can contain a stronger passphase take a keyboard typeable key, but can take any binary sequence (including returns and nulls) as the input key. As such you may need to remove that fina newline from the keyfile.
One method to do that is...
tr -d '\012\015' < keyfile > keyfile_no_linefeeds
ASIDE: LUKS form of cryptography key indexing also will let you can change your phasephrase without needing to re-encrypt the whole disk. That is the passphrase can be changed without changing the actual cryptographic key used to encode the disks data. Similarly you can even have multiple (up to 8) different passphrases that can be used to mount the encrypted disk.
My notes on dmcrypt (yes my notes go that far back), cryptsetup, and LUKS cryptsetup...
http://www.ict.griffith.edu.au/antho..._dmcrypt.hints
PPS: I used to use cryptsetup a lot in storing encrypted data, though I have now moved to using "encfs", a directory level file encryption. I thoroughly recommend it over block level level, whole disk encryption, unless you plan to encrypt all the disks of your whole machine.
A directory-level encryption allows me to store my encrypted files 'in the cloud' (such as dropbox) or on USB drives, or on any other filesystem (NTFS, EXT4, VFAT, NFS, SSHFS, etc) I like. The encryption remains completely local to the system, and can be copied or transferred or synchronized to another storage device or system (cloud) without needing to actually decrypt the filesystem! With some effort you can even hide multiple encfs encryptions in the same data store to provide a level of plausible undeniably about exactly how much encrypted data there actually is (use of chaff and help prevent rubberhose attacks).
See my notes on using encfs
http://www.ict.griffith.edu.au/antho...to/encfs.hints
