In an earlier entry I’ve changed generated key file used for disk encryption from 4096 to meagre 64 bytes. I gave no mention of that adjustment considering it unimportant but have since been enquired about security of such a short password.

Rest assured, a 64-byte key file is sufficient for any symmetric encryption (disk encryption being one example) and anything more does not improve security.

Even a modest 100 bits should be enough for the most paranoid amongst us, according to cryptsetup FAQ. 64 bytes is five times as many and recall that difficulty of breaking an encryption grows exponentially with the size of the secret.

Bet let’s crank it up to eleven. The largest cryptosetup supports (and will likely ever need to support) are 512-bit keys†. No matter how enormous encryption password is, ultimately at most 512 bits will be used. In other words, if key file is bigger it becomes easier to attack the derived encryption key instead.

And since brute-forcing 512-bit key would require roughly 2²⁸⁷ solar systems worth of energy (or 2²⁵⁰ Milky Way galaxies) a motivated adversary will focus on other methods of obtaining the password.

There is a small caveat. If the password was generated from a poor entropy source, instead of brute-forcing the encryption, guessing output of the pseudo random number generator should turn out much more rewarding. This is precisely how Debian’s OpenSSL vulnerability came about.

While it may be tempting to think a large file guards against such mishaps, PRNG is unable to concoct entropy. Guessing its initial state (which in case of aforementioned vulnerability was only 31 bits) is sufficient to predict its output to arbitrary length.

This is why I’ve also changed the command to use /dev/random which gives better guarantees regarding randomness of its output compared to /dev/urandom.

To sum up and reiterate, provided that good randomness source is used (hint: always use /dev/random), when creating a binary key file for a LUKS container, 64 bytes is plenty and even half of that is more than enough.

† 512-bit encryption key is used for 256-bit block ciphers in XTS mode. And even here the doubling of the size appears to be caused by misunderstanding of XEX algorithm rather than need for better security, see comments on XTS-AES by M. Liskov and K. Minematsu.