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 just 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
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.