Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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)
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.
