Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm studying mechanisms of integrity and authentication in symmetric encryption scenarios. I want to propose some examples to see whether I got the point here:

Let $m$ be the message, $c$ the ciphertext, $h$ the hashed message and $t$ the tag resulting of applying MAC.

Example 1:

Here Alice wants to send an enciphered message to Bob providing authentication and integrity but without using hash functions. Both parties agree on two different keys, $k_{1}$ and $k_{2}$. Alice applies $c=Enc_{k_{1}}(m)$ and computes $t=MAC_{k_{2}}(m)$. Then she sends $c$ and $t$ to Bob. Bob applies $m=Dec_{k_{1}}(c)$ and verifies $t'=MAC_{k_{2}}(m)$ comparing it to Alice's $t$.

Example 2:

Now Alice wants to send an enciphered message to Bob but also hashing the message $m$ for computing the MAC (so HMAC comes in). Both parties agree on two different keys (again), $k_{1}$ and $k_{2}$. Alice applies $c=Enc_{k_{1}}(m)$, computes the hash over the message $h=H(m)$ and finally computes $t=MAC_{k_{2}}(h)$. She sends $c$ and $t$ to Bob. Bob now deciphers $m=Dec_{k_{1}}(c)$, computes the hash $h=H(m)$ and verifies the MAC $t'=MAC_{k_{2}}(h)$ comparing it to Alice's $t$.

In case of CBC-MAC, I have read that both parties must agree on a fixed message length, since an attacker could forge a valid MAC. Is this issue solved when using HMAC?

Do you consider these two examples secure? Am I right or mistaken? Specially in the last one, where both parties use hashes with MAC (I have special interest in that one).

Thanks.

share|improve this question
3  
Actually, that's not the standard meaning of HMAC; HMAC usually refers to a specific MAC based on a hash function, specifically, $Hash( (OPAD \oplus K) | Hash( (IPAD \oplus K ) | Message ) )$ – poncho Mar 30 at 2:09
up vote 1 down vote accepted

There are a few things wrong with your scheme:

  1. if padding is used then your scheme may be vulnerable to padding oracle attacks, this is because decryption happens before MAC verification (see answer of curious);
  2. encrypt-and-MAC doesn't provide confidentiality as you can clearly distinguish identical plaintext as the authentication tag $t$ will be identical as well (see the comment of CodesInChaos below the answer of curious).

Notes:

  • It is a good idea to study the link that curious provides in the answer to understand more of the underlying issues;

  • HMAC is a specific construct (using just the hash as underlying primitive); it is not hash-then-CBC-MAC;

  • The issues of CBC-MAC are readily solved (for block ciphers that use 16 byte block size such as AES) by using the CMAC construction which is based on CBC-MAC but doesn't suffer the same issues for dynamically sized input.

share|improve this answer
    
I found that Mac-Then-Encrypt has been superseded by Encrypt-Then-MAC in TLS when possible. I guess that in some scenarios this isn't supported by both parties. Would be using MtE still considered secure? – kub0x Apr 1 at 22:13

Your techniques are not secure. It is the Encrypt and Mac method. Provides integrity to the message but not to the ciphertext. Check this answer. The most secure is to encrypt and then apply the mac to the ciphertext, or to apply an authenticated cipher to the message

share|improve this answer
3  
Also the biggest issue with encypt-and-MAC is that it doesn't provide confidentiality. – CodesInChaos Mar 30 at 7:32

Thanks to you all for your replies, specially @Maarten Bodewes who has given a complete answer to my questions.

So thing is that my scheme (Encrypt-and-MAC) doesn't provide confidentiality since the computation of two identical messages yields the samme tag/result. In terms of cryptography it will seem like: $Enc_{k_{1}}(m)$ $||$ $MAC_{k_{2}}(m)$. Notice that it provides integrity.

Also MAC-then-Encrypt is a bad choice since $Enc_{k_{1}}(m || MAC_{k_{2}}(m))$ doesn't provide integrity over the ciphertext.

Best option will be Encrypt-then-MAC: $c=Enc_{k_{1}}(m)$ then send $c$ $||$ $MAC_{k_{2}}(c)$ so confidentiality and integrity are achieved.

I viewed the lesson that covers HMAC here (Princeston University) -> https://www.youtube.com/watch?v=krJ3fHjXYlc Maybe I misunderstood the concept (though the Poncho's answer isn't explained there).

Finally, I would appreciate an explanation of why two keys $k_{1}$ and $k_{2}$ are needed, $k_{1}$ for plaintext encryption and $k_{2}$ for message authentication.

Thanks.

share|improve this answer
    
I've found the answer to my question regarding of the use of two keys for encryption and authentication in crypto.stackexchange.com/questions/8081/… We could derive two keys from the SHA-256 of our Master Key, or use a scheme as GCM which permits us to use one key for auth and encryption. – kub0x Apr 1 at 22:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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