0
$\begingroup$

I am using AES-CBC, authenticating using HMAC-SHA512 and I was wondering whether my thought process and implementation are correct.

The message send over the network is: HMAC(64Bytes),IV(16Bytes),Ciphertext The MAC is calculate as follows: HMAC(sha1(secretKey),Plaintext)

  • Is there a significant reason to use SHA-512 over SHA-256?
  • Should I treat the secretKey differently or generate a complete new pair entirely for the authentication of the ciphertext
$\endgroup$
2
$\begingroup$

I am using AES-CBC, authenticating using HMAC-SHA512 and I was wondering whether my thought process and implementation are correct.

The message send over the network is: HMAC(64Bytes),IV(16Bytes),Ciphertext The MAC is calculate as follows: HMAC(sha1(secretKey),Plaintext)

No, that's not correct.

The HMAC should be calculated over the IV and ciphertext values, not over the plaintext. If you send the HMAC over the plaintext then an attacker will be able to distinguish identical plaintext.

If this is used for transport security (as you seem to indicate) then you may be vulnerable to padding oracle attacks on the CBC mode AES. If you want to use a good scheme you could take a look at this draft RFC.

If you want to use it as application level protocol you may (also) want to read about the order of encryption and MAC. If push comes to shove you could use MAC-encrypt-MAC of course.

SHA-1 in this scheme only reduces the amount of key material if a 192 or 256 bit key is used.

Is there a significant reason to use SHA-512 over SHA-256?

Probably not for generating an authentication tag for a MAC. Note that SHA-512 is generally faster than SHA-256 on 64 bit machines, so if you can spare the bandwidth then it might be a good idea to use SHA-512. Otherwise you could use SHA-512/256 - if that's available on your target runtimes of course.

Should I treat the secretKey differently or generate a complete new pair entirely for the authentication of the ciphertext

You definitely should not put SHA-1 in the mix.

You could use the same key for encryption and HMAC if you're feeling dangerous. It's unlikely (but not theoretically impossible) that this will compromise the symmetric key.

If you want to do it nicely then you should use two keys. You could use a key derivation function such as HKDF to calculate two keys out of the master key. If that's not available you could fall back to the PRF used to generate the sessions keys within TLS.

$\endgroup$
  • $\begingroup$ Or you could of course fall back to TLS with a pre-shared secret to replace your entire protocol. As you can see the chance of getting transport security right is remote. $\endgroup$ – Maarten Bodewes Mar 23 '16 at 16:04
  • $\begingroup$ I changed the implementation now, and yeah you're right on that part ( TLS ) but so far this has been an amazing learning experience. Thanks for the information. $\endgroup$ – Antwan van Houdt Mar 23 '16 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.