9

I want to combine hashing and encryption for better security. So can I use a hash key generated from SHA-512 as a key in AES.

For example, I have a password "secret", I calculate SHA-512 hash for it and I want to feed those bytes as key for AES.

What things I need to care while implementing this?

Kaushal Khamar
  • 191
  • 1
  • 7
  • 9
    I would start with reading [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) on Wikipedia. – techraf Mar 21 '16 at 05:39
  • Thanks for reply @techraf. So i can use PBKDF2 instead of SHA to generate key? – Kaushal Khamar Mar 21 '16 at 05:47
  • Just check if what you want to invent isn't already standardized. – techraf Mar 21 '16 at 05:56
  • So PBKDF2 is more secure then SHA? I am going to use PBKDF2 for generating key for AES. – Kaushal Khamar Mar 21 '16 at 06:29
  • 2
    http://security.stackexchange.com/questions/16354/whats-the-advantage-of-using-pbkdf2-vs-sha256-to-generate-an-aes-encryption-key – Kaushal Khamar Mar 21 '16 at 06:31
  • 5
    You have a password, you need a key. That is exactly what a "key derivation function is"--it is something that creates a key from a password. SHA-512 is not a key derivation function, it is a hash, it is the wrong kind of thing to use. – Dietrich Epp Mar 21 '16 at 08:34

2 Answers2

21

Technically, not as stated. AES-256 requires a 256bit key. SHA-512 will output 512 bits so unless you chop off half of the digest it will not work.

A better solution is to use a standard and well tested key derivation function such as pbkdf2.

Don't roll your own crypto unless absolutely necessary. Use vetted constructions.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
d1str0
  • 2,348
  • 14
  • 24
  • One thing to note about chopping off half of the hash: This will remove half of the passwords's entropy! A hash function has the great advantage of evenly distributing an arbitrary amount of unevenly distributed entropy over the output value. Unluckily, when the input is already poor in entropy and you throw away half of the output, this is a huge, huge disadvantage. – Damon Mar 21 '16 at 12:25
  • 9
    @Damon that is not true. For a well-designed hash function, truncating a 512-bit hash to 256 bits should be equivalent to using a similar 256-bit hash. In fact, this is exactly how SHA-512/256 works. If your statement were true, then using SHA-256 would also lose half the entropy of a simple (let's say 64-bit) password, as compared to SHA-512. – marcelm Mar 21 '16 at 12:49
  • @marcelm: Given n bits of entropy input and a hash that has m>n bits of output, the hash retains all entropy (a password is unlikely to have more entropy than will fit a hash, so let's ignore that case). But the problem is, you don't know _where_ the entropy is, so just throwing away some part is problematic. 512 = 8*64, so each bit of input should affect 4 bits of output on the average. Might be 4 bits in either half, or might be 4 in the first quarter and 4 in the second quarter, you cannot know for sure (if you could tell so easily, the hash would be kinda pointless). There is a very... – Damon Mar 21 '16 at 13:02
  • ... similar example which I've encountered with curve25519 and which once made me wonder for a while. DJB recommends that you hash the generated key rather than just taking the lower 128 or so bits. That seems "OK", but a bit on the paranoia side, right? Hashing _doesn't hurt_, but shouldn't be necessary. But the truth is, those 256 bits coming out of the key exchange contain about 128 bits worth of "cryptographic strength" _and you don't know where they are_. Taking one half of the output doesn't guarantee that your key has a strength of 128 bits (in fact, it guarantees that it _doesn't_). – Damon Mar 21 '16 at 13:08
  • 4
    @Damon This is not how hash functions work. – Xander Mar 21 '16 at 14:31
  • @Damon You are right that it is possible to lose entropy using hash functions (in fact, it is extremely likely). However, that is far removed from your original comment stating that you'll lose half of the password's entropy by moving from a 512-bit to a 256-bit hash, which is still false for typical passwords. A SHA-512 hash of a password with 64 bits of entropy will have (almost) 64 bits of entropy, and so will a SHA-512/256 hash. – marcelm Mar 21 '16 at 16:16
  • @Damon Also, your statement "Given n bits of entropy input and a hash that has m>n bits of output, the hash retains all entropy" is not categorically true, because some of the possible inputs may collide and produce the same hash. So if you have 2^64 possible inputs, you might end up with (2^64)-1 distinct hashes, losing a tiny bit of the original entropy ;) – marcelm Mar 21 '16 at 16:20
-2

So far so good, but using SHA-256 as an AES key is a good practice, imho. Especially in the case of "text passphrase" - validate minimal length and complexity - and you're ready to go.

Alexey Vesnin
  • 1,565
  • 1
  • 8
  • 11
  • 1
    This is not a good plan. See the other answer and comments about using a PBKDF. – Xander Mar 21 '16 at 14:32
  • 1
    @Xander why it's no good? I'm not arguing about usefulness of PBKDF2 - but what the *exact* problem using sha-256 of 64+ characters long non-repeating passphrase's SHA-256 hash value? Would you be so kind to point it out? – Alexey Vesnin Mar 21 '16 at 19:25
  • 2
    @AlexeyVesnin The fact it hasn't been vetted and found to be secure is generally enough of a reason to avoid anything in security. If you don't deal with breaking crypto every single day, I don't trust you to come up with your own crypto scheme. How do you have *any* confidence that this doesn't create a subtle vulnerability? – jpmc26 Mar 21 '16 at 19:32
  • @jpmc26 *just* by the fact that there's no attack to break sha-256 so far. If you can not forge a passphrase, i.e. make two passphrases with the same hash and one passphrase must be shorter(for attacking speedup purposes), so you will be forced to bruteforce at least 64 bytes ling passphrase, i.e. the complexity is VERY high, and there's more than 2^128 variants even just using an alphabetical english letters just lowercase. – Alexey Vesnin Mar 21 '16 at 19:49
  • @AlexeyVesnin Your argument is a strawman. It has nothing to do with either the question asked by the original poster, nor anything to do with how we actually design general purpose systems in the real world. – Xander Mar 21 '16 at 19:53
  • @Xander maybe *you are* designing it like that, but none of *made by me* was hacked 18 years straight and so far : right from a moment I learned to do so. And this scheme was used more than 5 times in a *variety* of tasks. And they're still working unhacked, FYI. – Alexey Vesnin Mar 21 '16 at 19:55
  • 1
    @AlexeyVesnin according to [this answer](https://security.stackexchange.com/a/16357/97720), you are correct that there is no practical difference between using SHA-256 vs PBKDF2 ***provided that*** your passphrase is long and random-enough to resist systematic enumeration. The practical advantage of PBKDF2 is that it's "slow by design" in order to make brute-forcing the pre-image much harder than with SHA-256 (which is "fast by design"). I'm no expert, that's just what I read in the linked answer –  Oct 29 '17 at 02:31