# SHA-256 and AES-128

Does it make an encrypted string more secure if I use SHA256(x) instead of x as the secret key for AES-128 encryption? I do know that SHA-256 produces 64 characters of hashed string regardless of what the input is.

Will it still be accepted in AES as a key or it will cut it off to 32 characters? Also is it true that each byte is equivalent to 8 bits (e.g. if I enter xkcd it will be 32 bits)?

-
Do you want to use a password, or a random key? Turning passwords into keys has some extra requirements. You should not just send it through SHA-256 or put it directly into the key. –  CodesInChaos Sep 21 '12 at 12:13
I think you have some mistakes in your question. $128$ bits is $16$ bytes. One character is typically $1$ byte, so the secret key for AES-128 would be 16 characters. SHA-256 output is 32 bytes, so 32 characters. Also, I'm not sure what you mean by each byte is equivalent to 8. Each byte is 8 bits. Is that what you mean? –  mikeazo Sep 21 '12 at 12:15
I want to use a password. –  Aron Jay Sep 21 '12 at 12:16
Yes, I mean 8 bits per byte. And I strongly believe that SHA-256 produces an output of 64 characters. –  Aron Jay Sep 21 '12 at 12:19
@AronJay, it all depends on your encoding. But SHA-256 output is 256 bits which is 32 bytes. Now, if you are using hex encoded output (you probably are), each 4 bit value is encoded as a single character (0-9,A-F). Thus you will get 64 characters. But, those 64 characters have a maximum entropy of 256 bits or 32 bytes. –  mikeazo Sep 21 '12 at 12:32

First let's take care of your encoding related issues:

You can't simply say one byte equals one char. You need an encoding to transform between these, where the properties depend on that encoding.

When transforming between normal text and bytes, UTF-8 is a good choice. One character will correspond to a variable amount of bytes that way. You'd use this to turn a password into bytes. xkcd would result in 4 bytes, but non ASCII characters, such as ü will result in more than one byte per char.

When turning arbitrary binary data into text, use an encoding specialized in that. Hex is very popular, turning each byte into two characters. Base64 which turns 6 bits into one char is a common alternative.

Now SHA-256 returns 32 bytes of binary data. If you use hex encoding on that, you get 64 chars.

AES-128 takes a 16 byte key, which corresponds to 32 characters in hex encoding.

Next we get to your key derivation issues:

The problem with passwords is, that they tend to be weak, compared to random keys. So you need to send them through a key-derivation-function, that makes password guessing attacks more difficult.

SHA-256 is not a good choice for this, because it's fast. You should use a deliberately slow function, such as PBKDF-2, together with a random salt.

When using AES-128 truncate the output of it to 128 bits (or explicitly request 128 bits if your KDF supports that). Your password will be much weaker than even a 128 bit key, so there isn't much gain in using 256 bit keys.

-

The proper way to do things in this case would be to feed the password to a key derivation function such as PBKDF2. PBKDF2 (and other KDFs) is designed specifically for what you describe. Since you are using AES-128, you would want a 128-bit output from PBKDF2, then feed that into AES.

Now, stepping back a little, the best advice I can give you is to not roll your own crypto protocol and instead use a widely accepted standard. If you are doing file encryption, PGP (or GPG on the open-source side) is the way to go. If you are encrypting network traffic, you should be using SSL or IPsec. Providing us with more information as to what you are specifically doing would allow us to provide better guidance.

That said, perhaps you are doing this as a learning exercise. In that case, I think the first paragraph is the best advice I can give.

-