# Encrypt-then-MAC Confidentiality, Integrity and Authenticity

Does Encrypt-then-MAC provide equal confidentiality, integrity and authenticity as other constructs such as EAX? If yes, how do I go about using it?

My current understanding is:

1. E = encrypt(plaintext)
2. H = hash(E)
3. output(H || E)

Is that correct?

Encrypt-then-MAC has been standardized in ISO/IEC 19772:2009 hence it is safe to assume all the properties that you mentioned.

To the best of my knowledge, the best way to perform EtM is:

E = ENCRYPT(PLAINTEXT)


I am assuming that you are using a block cipher such as AES and appending the encryption IV or nonce to the start of E unless of course you are using ECB.

M = HMAC(E)


HMAC also takes a key which must be different from your encryption key. There are of course other MACs, but I recommend HMAC since it removes the complexity of MAC IVs.

OUTPUT E, M

• I'm using AES in CBC Mode and concentrating the initialization vector to the end of the message. Is it correct to include the encryption initialization vector along with the encrypted data in the HMAC? Can anyone else confirm this idea? – John Black Oct 11 '11 at 10:34
• I don't see why not... – Chris Smith Oct 11 '11 at 20:44

Not quite. The reason you don't want to compute $H(E)$ is that anyone can compute that, given they know what function $H$ is and so your recipient will not be able to verify the response. What you're looking for is called HMAC (RFC 2104) which includes two other components: a key and padding.

Specifically, given some secret $s$, some message $m$, $p_o = 0x5c5c5c...$, $p_i = 0x363636...$, a suitable hash function $H$, $\oplus$ meaning the xor operation and $||$ meaning append then the HMAC scheme is:

$$HMAC(k, m, H) = H((k \oplus p_o) || H((k \oplus p_i) || m)).$$

Some notes:

• $B$ is the block-length in bytes of the hash function. Most hash functions accept quite large blocks ($B = 64$). $L$ is the output length of the hash function. A 512 byte hash (SHA-512) would give you $L=9$ ($2^9=512$).
• $k$ is the key. It is probably worth quoting the RFC in its entirety for this:

The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak.)

Keys need to be chosen at random (or using a cryptographically strong pseudo-random generator seeded with a random seed), and periodically refreshed. (Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key.)

To answer your other question, the EAX paper might be of interest. Specifically, EAX is built upon the OMAC construct which provides a message authentication code system based on a block cipher. As such, both systems essentially use MACs, but EAX's comes built in.

• Thanks for the clarifications about HMAC and EAX but how do I go about implementing Encrypt-then-MAC, would you agree with the implementation steps @Chris Smith provided? – John Black Oct 11 '11 at 10:29
• @JohnBlack yes. In general $m$ should be the encrypted output (which may or may not include IVs depending on the protocol etc) and $k$ the MAC key. So then you calculate your MAC from the encrypted data, which prepends the MAC according to HMAC. Then to verify, the recipient can use the same encrypted data and the key - calculate the MAC and compare. If it isn't valid, they discard the message. – user46 Oct 11 '11 at 22:18