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?

Improve this question
6
  • 9
    I would start with reading PBKDF2 on Wikipedia.
    – techraf
    Commented Mar 21, 2016 at 5:39
  • Thanks for reply @techraf. So i can use PBKDF2 instead of SHA to generate key?
    – Kaushal Khamar
    Commented Mar 21, 2016 at 5:47
  • Just check if what you want to invent isn't already standardized.
    – techraf
    Commented Mar 21, 2016 at 5:56
  • 2
    security.stackexchange.com/questions/16354/…
    – Kaushal Khamar
    Commented Mar 21, 2016 at 6: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
    Commented Mar 21, 2016 at 8:34

2 Answers 2

Reset to default
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.

Improve this answer
7
  • 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
    Commented Mar 21, 2016 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
    Commented Mar 21, 2016 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
    Commented Mar 21, 2016 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
    Commented Mar 21, 2016 at 13:08
  • 4
    @Damon This is not how hash functions work.
    – Xander
    Commented Mar 21, 2016 at 14:31
-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.

Improve this answer
7
  • 1
    This is not a good plan. See the other answer and comments about using a PBKDF.
    – Xander
    Commented Mar 21, 2016 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
    Commented Mar 21, 2016 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
    Commented Mar 21, 2016 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
    Commented Mar 21, 2016 at 19:49
  • 1
    @AlexeyVesnin according to this answer, 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
    – user97720
    Commented Oct 29, 2017 at 2:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .