Recently I have begun playing with whole disk encryption on my "servers" - really backup/archive data storage boxes & part time NAS. I have created the encrypted partitions with cryptsetup & luks (CentOS 7 and Ubuntu 16.04). I added a key file and the partitions will unlock and mount using entries in /etc/crypttab and /etc/fstab. I still have the original passphrase associated with the encrypted partitions in case the keyfile is lost or corrupted.

In order to step up my security game I could remove the passphrase and make the partitions rely only on the key file. This of course necessitates some redundant backup of the key file. Which got me thinking (always dangerous )

To quote Basil Rathbone (as Sherlock Holmes in the movie The Secret Weapon) "I have always believed in the theory first put forward by the American author Edgar Allen Poe that the best place to hide something is where everyone can see it." Which gave me the idea to use some binary file which I have on my computer and which I have backed up already. For example I might take the file FOXSWAP.COM 5.8k (part of FoxPro for DOS which I still use to run a little expense tracking application which I wrote in 1986), rename it and use it as the key file. If the key file was lost I would know where to get a replacement copy from.

Which brings me to the question of this post... A machine language binary file would probably be just fine as a key. Most references I have read speak of using /dev/urandom and dd to create the file. This is in fact the approach I took for the initial key file. What about...

Suppose I take some pdf file - say my November 2002 bank statement, start at some offset known only to me and snag a few k of bytes - again only known by me? Provided I do not get a chunk of the file which is full of nulls, would this work just as well?

What about a couple of pages of a book or a historic document keyed into an ascii file? Would either of those be less effective than a "pure" binary file?

TIA,

Ken

My understanding is that the key data gets run through something like hmac to generate a seed for the internal crypto code. Even a 1-bit difference in input will give a completely different seed. So I see no problem with your approach as long as you use enough key material.

This assumes the attacker will be trying to guess the output of the hmac instead of trying to guess the input by, e.g. going through all the books in the library.

Your bank statements are probably safer, since if the attacker can get to those they've probably already broken into your bank which is more valuable than any data you've encrypted. Unless they can reconstruct the statements by dumpster diving?

Also make sure you don't get a chunk of the file which is identical across many pdfs (e.g., some kind of font data).

Thanks smallpond,

I am a little confused about the relationship of the key file to the strength of the encryption of my data. The data was encrypted when it was first copied to the encrypted partition. The encrypted partition was originally protected with a pass phrase. The key file was added later and did not cause the data to be re-encrypted. Obviously the keyfile is working at a different level than the "encryption/decryption of the data" process. I need to do some serious reading.

I am considering purchasing a copy of Applied Cryptography by Bruce Schneier. I found some used copies on abebooks.com at reasonable prices. However, it is my understanding that the latest printings have typo corrections lacking in earlier printings. I have to find a corrected printing. One little typo in a code sample can ruin your whole day. I make enough typos on my own

Thanks again,

Ken

You can have up to 8 different keys/passphrases for each encrypted volume, so multiple keys may be added or removed. Use luksDump to see what's going on.

Thanks again smallpond,

I have played with adding and deleting passphrases and key files from an encrypted volume and examining the situation with luksDump. I have some understanding of the importance of a strong password or passphrase - to prevent "human" guessing or dictionary attacks etc. Just trying to get my head around the "strength" of a binary key file.

Ken