2

Let's say I would like to have "password-derived-bytes" as AES key. For example, I have a password "topsecret", I do calculate SHA-1 hash for it (160bit) and I want to feed those bytes as key for AES-128.

Should I just truncate after 128 bits or do some kind of folding? What about AES-256? Should I repeat bytes, pad with 0's or do some "unfolding" operation?

I know that in the later case security remains at 160-bit because the pool of 256-bit passwords is reduced to 2^160 possible combinations, but I'm just trying to overcome technical limitation (no AES-160).

What theory says? (No, using MD5 for 128-bit and SHA-256 for 256-bit long hashes is not an option)

Milosz Krajewski
  • 1,160
  • 1
  • 12
  • 19
  • just to be clear here (echoing ntoskml) your security is NEVER 160 bits. taking the hash of a poor password does not give you more security - an attacker can also take the hash of each word in the dictionary. – andrew cooke Nov 08 '13 at 17:00
  • @andrewcooke: You are right and I was aware of this. I could have been more precise. What I meant is SHA-1 is limiting security to 160 bit. Regardless how strong password I do using SHA-1 will limit it's security to *maximum* 160 bit. – Milosz Krajewski Nov 08 '13 at 20:35
  • pbkdf wil give you as many bytes as you need. for purely "educational purposes", if you have a password of more than 160 bits entropy you can generate a key preserving that by doing `sha1(password) + sha1(byte(0)+password)` and taking 256 bits from that. you can add anything to the password in the second case. although i must admit i have no reference for that, but you can see the idea from the fact that changing any bit in the password has a 50% chance of changing any of the bits in the 256 bits, independently. – andrew cooke Nov 08 '13 at 20:52
  • (assuming the hash is sound, of course) – andrew cooke Nov 08 '13 at 21:02
  • Note that you need *a lot* of entropy for secret keys. As an example, 56-bit DES keys are pretty much worthless because they can be brute forced in 20 hours with current hardware. With passwords, the situation is pathological – running a 10 million word dictionary through SHA-1 and trying each key takes only seconds on a home computer. This is why password-based encryption takes the different approach of making the key derivation process expensive. – ntoskrnl Nov 08 '13 at 22:41

2 Answers2

5

A typical password only has a few dozen bits of entropy, and running a password through a hash function does not add any entropy to it. Therefore, such keys are easily attacked using a dictionary or brute force.

The most commonly accepted solution is to make the hash function very slow. Algorithms designed for this are called "password-based key derivation functions". PBKDF2 and bcrypt are among the most popular ones.

ntoskrnl
  • 5,714
  • 2
  • 27
  • 31
3

Theory says that it does not matter. You can pad with 0's, you can pad by repeating, etc. The amount of entropy in your result is the same - it's equally hard to brute force.

As for truncating it to 128 bits, it doesn't matter how you truncate it - all the bytes of the hash output are generally considered equally random and uncorrelated. There is no "more entropic" side or something.

So, technically, do as you will - you remain as strong as your password.

Murph
  • 1,479
  • 2
  • 13
  • 26
  • As the answer is completely correct, the other one does provide a hint about PBKDF2 and I have to pick one. So I'm accepting ntoskml's. – Milosz Krajewski Nov 11 '13 at 11:16