posts/key-file-size.en.html

   1 <!-- subject: PSA: Yes, 64-byte key file is okay -->
   2 <!-- date: 2017-04-04 23:14:55 -->
   3 <!-- tags: luks, encryption, cryptography -->
   4 <!-- categories: Articles, Techblog -->
   5
   6 <p>In <a href="/2017/psa-chmod/">an earlier entry</a> I’ve changed
   7   generated key file used for disk encryption from 4096 to meagre 64
   8   bytes.  I gave no mention of that adjustment considering it
   9   unimportant but have since been enquired about security of such
  10   a short password.
  11
  12 <p>Rest assured, a 64-byte key file is sufficient for any symmetric
  13   encryption (disk encryption being one example) and anything more
  14   does not improve security.
  15
  16 <!-- FULL -->
  17
  18 <p>Even a modest 100 bits should be enough for the most paranoid
  19   amongst us, according
  20   to <a href="https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions">cryptsetup
  21   FAQ</a>.  64 bytes is five times as many and recall that difficulty
  22   of breaking an encryption grows exponentially with the size of the
  23   secret.
  24
  25 <p id=b1>Bet let’s crank it up to eleven.  The largest cryptosetup supports (and
  26   will
  27   likely <a href="http://security.stackexchange.com/questions/6141/amount-of-simple-operations-that-is-safely-out-of-reach-for-all-humanity/6149#6149">ever
  28   need to support</a>) are 512-bit keys<a href=#f1><sup>1</sup></a>.  No matter how
  29   enormous encryption password is, ultimately at most 512 bits will be used.  In
  30   other words, if key file is bigger it becomes easier to attack the derived
  31   encryption key instead.
  32
  33 <p>And since
  34   <a href="http://security.stackexchange.com/questions/6141/amount-of-simple-operations-that-is-safely-out-of-reach-for-all-humanity/6149#6149">brute-forcing
  35     512-bit key would require roughly 2<sup>287</sup> solar systems worth of
  36   energy</a>
  37   (or <a href="http://www.space.com/25959-how-many-stars-are-in-the-milky-way.html">2<sup>250</sup>
  38   Milky Way galaxies</a>) a motivated adversary will focus on
  39   <a href="https://xkcd.com/538/">other methods</a> of obtaining the
  40   password.
  41
  42 <p>There is a small caveat.  If the password was generated from a poor
  43   entropy source, instead of brute-forcing the encryption, guessing
  44   output of the pseudo random number generator should turn out much
  45   more rewarding.  This is precisely
  46   how <a href="https://www.schneier.com/blog/archives/2008/05/random_number_b.html">Debian’s
  47   OpenSSL vulnerability</a> came about.
  48
  49 <p>While it may be tempting to think a large file guards against such
  50   mishaps, PRNG is unable to concoct entropy.  Guessing its initial
  51   state (which in case of aforementioned vulnerability was only 31
  52   bits) is sufficient to predict its output to arbitrary length.
  53
  54 <p>This is why I’ve also changed the command to
  55   use <code>/dev/random</code> which gives better guarantees regarding
  56   randomness of its output compared to <code>/dev/urandom</code>.
  57
  58 <p>To sum up and reiterate, provided that good randomness source is
  59   used (hint: always use <code>/dev/random</code>), when creating
  60   a binary key file for a LUKS container, 64 bytes is plenty and even
  61   half of that is more than enough.
  62
  63 <p id=f1><a href=#b1>1</a> 512-bit encryption key is used for 256-bit block
  64   ciphers in XTS mode.  And even here the doubling of the size appears to be
  65   caused by misunderstanding of XEX algorithm rather than need for better
  66   security,
  67   see <a href="http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/XTS_comments-Liskov_Minematsu.pdf">comments
  68   on XTS-AES by M. Liskov and K. Minematsu</a>.