3 Answers
3

Is the calculated MAC encrypted using AES? What is the purpose? How
about signing and verifying? How does AEs Play a role here? Is the
case here that the encrypted AES is HMACed for signing and the HMAC is
verified

No, the MAC is not encrypted per se, however, it is calculated in conjunction with a key (independent of the encryption key).

Simply encrypting your data ensures privacy, however, it doesn't ensure integrity (ie, that the ciphertext hasn't been tampered with since it was encrypted). Using a HMAC provides this integrity.

A simple hash function by itself is not sufficient, as an attacker could alter the ciphertext, calculate a new hash, append it to the new ciphertext, and you would be unable to detect any tampering. A HMAC solves this problem as it uses a key - meaning that an attacker is unable to create a valid HMAC unless they have a valid key (which only you possess).

You should note that if you plan to encrypt-then-HMAC, you not only need to calculate the MAC of the ciphertext, but also the IV ...ie, HMAC((ciphertext+IV), key)

You should also note that independent keys should be used for the encryption (AES, for example) and the authentication (HMAC). One approach is to use a masterkey, and then derive two separate keys using a KDF.

Of course, using an authenticated encryption mode such as GCM or EAX is less prone to implementation errors (assuming you're using a well-vetted library), and is recommended if you don't have much experience in crypto.

Can you Elaborate on the use of one master key? At the Moment I have this crypto library that is a Blackbox to me and when I fed a 128 bit AES key and choose AES with HMAC Sha1 it works. The same Routine seems to also work with a 160 bit key. So I am a bit lost.
–
user907810Oct 31 '13 at 13:57

@user907810 - I can't speculate as to what's happening internally in your library. Regarding a 'master key', well assuming you begin with a 128-bit (minimum) cryptographically strong key (the master key), you could use something like HKDF to derive encryption and authentication keys.
–
hunterOct 31 '13 at 15:37

HMAC can be used with any key size (as the key is basically used as input for the underlying hash function). If the key size is too small then the security of the HMAC is of affected. In general, the key size should be at least the output size of the hash algorithm divided by two. It is best practice to use a separate key for calculating the HMAC though.

There are a lot of discussions if you should encrypt apply the MAC or the other way around. Encrypt and then MAC is best practice. One of the bigger reasons is the vulnerability of padding oracle attacks on e.g. CBC. To avoid these you must verify the MAC value before decryption. HMAC itself does not use the AES algorithm in any way (the AES-CMAC algorithm does but that algorithm requires an additional key).

The AES cipher does normally not play a role in signing/verifying, unless it is used in a cipher based MAC algorithm like the previously mentioned AES-CMAC algorithm.

Yes, it is correct that the AES ciphertext is HMAC-ed for signing and the HMAC is verified.

MAC (Message authentication code) is being used for message integrity and signatures for sender authenticity. That means that in an unauthenticated channel you need a way in order to be assured that the message received by Alice is coming actually from Alice (public signature) and the message has not being altered from an adversary(message integrity- MAC).

HMAC is one way in order to compute the MAC.
Once you have encrypted with a secure block cipher as AES your data, THEN you MAC your data with your MAC key and you send AES(Data)+MAC(AES(DATA)). The order is important. First you must encrypt and then compute the MAC. If you don't do it this way there might be flaws. If you don't want to use this approach you can use a by construction authenticated mode of symmetric encryption