1
$\begingroup$

I have seen some applications use key expansion when deriving AES-keys. E.g. the application will generate some random data (e.g. 128bits), then use PBKDF2 to expand it into 512bits (2x256 keys).

Why go through this process of taking a small amount of random and expanding it, instead of taking 512bits cryptographic randomness directly?

The random 'seed' value is not stored either so it can be reused for the key expansion.

$\endgroup$
  • 1
    $\begingroup$ Using PBKDF2 on a uniformly random seed already smells funny. Someone who wrote that may not truly understand what they're doing. There may in fact be no good reason to do so, but just because I can't think of one doesn't mean that there isn't one. Do they do anything like sometimes supply a password instead of that random seed? Maybe they re-use that function for passwords too. $\endgroup$ – Ella Rose Jan 28 '18 at 16:37
  • $\begingroup$ I'm guessing the key stretching is primarily used for stretching a user password into multiple encryption keys, setup at e.g. registration. However, this technique was reused with a random value as 'password' when generating keys to encrypt data items/files. That seemed odd to me, and I was wondering if there is any reason for doing that. $\endgroup$ – Eivind Jan 28 '18 at 18:00
  • $\begingroup$ Re-use of code is possibly an answer then. Also, it may be a counter measure against the system random not being seeded with enough entropy. $\endgroup$ – Ella Rose Jan 28 '18 at 18:41
  • 1
    $\begingroup$ Note that many runtimes, for instance the normal Java runtime from Oracle, do not supply any KBKDF's by default. The use of a PBKDF such as PBKDF2 as replacement for a KBKDF could well be the reason. And in that sense there could be worse choices, especially if few iterations are used. $\endgroup$ – Maarten Bodewes Jan 28 '18 at 19:33
1
$\begingroup$

The main reason is that true random data is hard to obtain; whether it is from:

  • A user's password since people only remember them so long

  • Or from a random source such as an operating system that reads random measurements like disk latencies since it can only produce so much randomness per unit time.

$\endgroup$
  • $\begingroup$ So this could be a reasonable measure against lack-luster random generators/entropy? $\endgroup$ – Eivind Jan 28 '18 at 19:23
  • $\begingroup$ The actual entropy of the output is equal to the input, though it seems (to a polynomial adversary) that it has doubled since the co-domain is twice as big.The seed does not need to be re-used since the expanded is what will be remembered and used. $\endgroup$ – Jackoson Jan 29 '18 at 13:13
  • $\begingroup$ Ok, so if I have sufficient randomness (this operation is very low frequency), it is safe to use the cryptographic random number generator of the platform to generate the entire key? $\endgroup$ – Eivind Jan 29 '18 at 14:53
  • 1
    $\begingroup$ Sorry, I haven't been particularly clear. In general when you want a random number yes! However, in this case (AES keys) the reasons are different (my fault). The encryption/decryption function actually uses a 44*4*8 bit long key, yet as user we don't want to store our key that is that long. Instead they just use the seed as the key. $\endgroup$ – Jackoson Jan 30 '18 at 10:15
  • $\begingroup$ I think maybe when you say the random seed is not stored, it is maybe because it is just passed in to the function every time as the key. $\endgroup$ – Jackoson Jan 30 '18 at 10:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.