Store encrypted MAC key inside encrypted file?

Question

In order to have an encrypted file who's key can be changed without needing to encrypt the whole file again, I'd like to encrypt the file with a main key ,and then encrypt that main key with another one which the user will keep.

My question is - can I also encrypt a MAC (Message Authentication Code) key and store it in the file beside the MAC itself, or will that introduce a weakness? (The user will have another MAC key to authenticate the main (encrypted) encryption and MAC keys.)

Let's assume using AES-CBC and HMAC-SHA256

EDIT

This is the general idea:

1. Encrypted main_AES_Key || main_MAC_Key (encrypted with user-stored_AES_Key).
2. IV.
3. MAC of all of the above (using user_stored_MAC_Key).
4. Encrypted message (using main_AES_Key).
5. IV.
6. MAC of 4+5 (using main_MAC_Key).

Answer 1

$\newcommand{\EtM}{\mathit{EtM}}\newcommand{\concat}{\mathop{\Vert}}$Fix a secret-key message encryption scheme $E(k, n, m)$ and a secret-key message authentication code $M(k, n, m)$, which you combine using encrypt-then-MAC by $$\EtM(k_0, k_1, n, m) = E(k_0, n, m)\concat M(k_1, n, E(k_0, n, m)).$$ Is it safe to store $$n\concat\EtM(k_0, k_1, n, k_0'\concat k_1')\concat n'\concat\EtM(k_0', k_1', n', m)$$ for some long message $m$, so that you can swap out $k_0$ and $k_1$ without having to re-encrypt anything under the long-term keys $k_0'$ and $k_1'$?

Generally, yes—assuming all the keys are chosen independently uniformly at random, the security contracts of $E$, $M$, and encrypt-then-MAC are satisfied, provided you pick a different nonce $n$ each time (and unpredictably, if $E$ is AES-CBC).

You can also reduce the storage needed for keys from (say) a 512-bit concatenation of two 256-bit keys down to a single 256-bit key, by deriving $k_0$ and $k_1$ from some single swappable key $k$, and $k_0'$ and $k_1'$ from some single long-term key $k'$, using a key derivation function such as HKDF or the ‘SHAKE’ extendable output functions (‘XOFs’) of SHA-3 or similar.

Or you could just use NaCl crypto_secretbox_xsalsa20poly1305 or libsodium crypto_secretbox_xsalsa20poly1305 instead of cooking up your own authenticated-encryption out of a block cipher and HMAC. (AES-GCM may not be a good choice here because I infer from context that you probably don't have an easy way to pick $n$ sequentially, and the AES-GCM nonce is not large enough to pick safely at random.)