2

We all regularly use password based, key derivation functions, however something that strikes me as counter intuitive is how PBKDF can somehow "stretch" the entropy of a supplied password to generate crypto graphically secure keys.

i.e. how does "hdk3mnt4k%@^" (a reasonable password), get stretched in terms of entropy by a PBKDF to generate a 256bit Sym or Asym private key?

Luis Casillas
  • 14,468
  • 2
  • 31
  • 53
Woodstock
  • 1,384
  • 1
  • 13
  • 23
  • 2
    It really depends on your definition of "entropy"; what's yours? – poncho May 02 '19 at 19:16
  • 1
    Quality of the randomness used for the final output key... – Woodstock May 02 '19 at 19:29
  • 1
    @Woodstock That's the wrong definition – Future Security May 02 '19 at 21:10
  • You might find the concepts of Kolmogorov or Algorithmic complexities useful, especially the fractal on the right. Those paradigms allow for your notion of entropy stretching via some form of generator (KDF, PRNG, PNG etc) as $ KDF:{0,1}^{66} \to {0,1}^{256} $, where 66 is the estimated password entropy. – Paul Uszak May 02 '19 at 22:12
  • 2
    @PaulUszak Well... there are algorithms involved. Kolmogorov complexity won't help them understand. At best, someone might realize that given a not-so-random-looking they can algorithmically derive a (uniform) random-looking output. The concept of complexity does not tell you anything about entropy. Nor does it tell you why password-stretching functions are used. The correct response here is simple: It's a common misconception. No deterministic algorithm can increase entropy --Also, ${0,1}^{66}$ means a string consisting of 66 symbols, each '0' or '1'. PBKDF2 accepts arbitray length input. – Future Security May 03 '19 at 01:22
  • @Future Security - why is it wrong? – Woodstock May 03 '19 at 06:24
  • 66 is my estimated entropy of hdk3mnt4k%@^ as 12 of 26 small chars, 10 digits and 10 of those other funky ones. – Paul Uszak May 03 '19 at 10:56

2 Answers2

7

however something that strikes me as counter intuitive is how PBKDF can somehow "stretch" the entropy of a supplied password to generate crypto graphically secure keys.

PBKDF2 and other slow KDFs don't increase the actual entropy, but increase its effective entropy. That is, a KDF can make a weaker password with relatively low entropy take as long to attack as a password with slightly higher entropy. Let's say you have a password with 50 bits of entropy. This means it has a keyspace of 250. If you halve the speed of the password hash by using two hash iterations instead of one, the keyspace stays the same, but the effective difficulty of cracking it has increased by one bit, to 251. Double the number of iterations again, and now you have the effective keyspace of 252. If we use 65,536 hash iterations (equivalent to doubling the number of hash iterations 16 times), we've increased the effective security by 16 bits. This would mean cracking your 50-bit password would require up to 266 hash operations instead of 250, making it as difficult to break as a genuine 66-bit password.

how does "hdk3mnt4k%@^" (a reasonable password), get stretched in terms of entropy by a PBKDF to generate a 256bit Sym or Asym private key?

I think you may be misunderstanding the purpose of PBKDF2. All it does is force an attacker to perform more work for each password guess than they would have to otherwise. When you're turning a password into a 256-bit key, you aren't actually increasing its entropy to 256 bits, just increasing its size. This can be done by any 256-bit cryptographic hash algorithm, whether it's a KDF or not. A hash algorithm takes an input of arbitrary size and generates an output of a fixed size. It is designed such that it is computationally-impractical to discover an input that hashes to a specific output, and it attempts to ensure that each input has a unique output (within the limits imposed by the pigeonhole principle).

forest
  • 15,253
  • 2
  • 48
  • 103
  • 2
    Ahh I think I got my mistake, attackers on files encrypted using a PBKDF don’t attack the 256bit key directly in the hope it had poor entropy. Instead they attack the PBKDF with possible way passwords? Is my definition of entropy equating to randomness of the key wrong? (As someone stated above) – Woodstock May 03 '19 at 06:26
  • @Woodstock Exactly! An attacker has to use the same KDF function that you use because directly attacking a 256-bit key is impossible. Whereas you are probably totally fine with waiting 500 milliseconds to see if your password is correct or not, this would seriously slow down an attacker. It would force them to guess two passwords per second instead of a hundred million per second, for example. – forest May 03 '19 at 06:27
  • thank you!! One last thing, is my definition of entropy being equatable to randomness of the key correct? (Someone above said it’s not). – Woodstock May 03 '19 at 06:33
  • @Woodstock Not quite. There are some other questions on this site with answers that explain the definition of password entropy. Try browsing through https://crypto.stackexchange.com/search?q=password+entropy. – forest May 03 '19 at 06:36
  • Everything I read on the site indicates that in terms of information theory, entropy is a calculation of the predictability of the composition of a key or password. So isn’t that fair to say it’s an estimate of the quality of the key/password and ergo related to the randomness of the same? – Woodstock May 03 '19 at 07:12
4

Password hashing does not increase entropy, no deterministic algorithm can do that. The purpose of a KDF is to increase the difficulty of a brute-force (or dictionary) attack by making the testing of candidate passwords slow.

For example, if your passwords are drawn from a distribution with say 48 bits of entropy then with a reasonable computer one could try 10^8 AES keys per second, breaking breaking the encryption in less than a month. By requiring an attacker to first use a slow KDF for each candidate key, we can reduce then number of possible keys/second to around 100, meaning an attack would take thousands of years.

Tjaden Hess
  • 289
  • 3
  • 8