# Distinct MAC and Key for AEAD?

I am implementing some of the algorithms in RFC 7518 and I noticed that AES_CBC_HMAC_SHA2 contains the following paragraph:

1. The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as follows. Each of these two keys is an octet string.

  MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in order.
ENC_KEY consists of the final ENC_KEY_LEN octets of K, in order.


The number of octets in the input key K MUST be the sum of MAC_KEY_LEN and ENC_KEY_LEN. The values of these parameters are specified by the Authenticated Encryption algorithms in Sections 5.2.3 through 5.2.5. Note that the MAC key comes before the encryption key in the input key K; this is in the opposite order of the algorithm names in the identifier "AES_CBC_HMAC_SHA2".

Why would the encryption key be different than the MAC key? The examples I see in wikipedia show that the same key is used for both.

My understanding is that because in JWE only the message is authenticated, it means that the key is available for tempering and since the MAC key and the MAC are in a known location, it should be possible to forge messages.

Am I incorrect in that assumption? Why did the RFC authors chose to split the keys instead of reusing it?

• Note that SIV uses the same construct. I'm not a fan of it; it could play merry hell when trying to derive keys within a HSM, to name one issue, and the keys need then to be split up anyway. If you design an AEAD scheme having it accept a single (AES) key is certainly preferred from the view of most users. Special types of key with double the size of normal keys are hard to handle. – Maarten Bodewes Apr 27 '18 at 10:28