# Is it safe to compute HMAC(Base64(IV) || “,” || Base64(CipherText)) instead of HMAC(IV || CipherText)?

Let || be the concatenation operator.

Let CipherText = AES(Key1, IV, Message).

Let us assume AES is used in CBC mode.

I want to compute an HMAC tag on the IV and CipherText.

Normally, one would do the following:

Tag = HMAC(Key2, IV || CipherText)


I want to know if the following would also be equally secure:

Tag = HMAC(Key2, Base64(IV) || "," || Base64(CipherText))

• @kelalaka Why is second better? What difference the presence or absence of , makes to the security of the scheme? – Lone Learner Oct 13 at 19:17
• @LoneLearner nothing, it is about  did you forget "," on the first one – kelalaka Oct 13 at 19:20

I want to know if the following would also be equally secure

Yes, both schemes are equally secure. Also for what you are trying to achieve you really shouldn't puzzle things together yourself but rather use pre-made modes like AES-GCM, AES-EAX or ChaCha20-Poly1305.

In fact, we can prove the above claimed security equivalence. Because Encrypt-then-MACis easily proven secure if the MAC is a vector-PRF (or vector-MACs) (i.e. a PRF that takes a triple of IV, associated data and ciphertext instead of a string as input) we're gonna prove the equivalence of these two vector PRFs and argue why the first one is a vector PRF.

$$F_K(IV,\perp,C)=\operatorname{HMAC}(K;IV\|C)$$ is a vector-PRF assuming HMAC itself is a normal PRF. To see this first note that IV has fixed length in all cases and thereby the concatenation is unambiguous, that is you always know what part is the IV and which part the ciphertext. Now because of this whenever the input to $$F$$ is different, so is the input to HMAC and because HMAC is a PRF we get a freshly chosen random string in that case which makes the behaviour indistinguishable from a vector MAC.

Next we'll prove that if $$f_1$$ and $$f_2$$ are injective and if $$f_1$$ has a data-independent output length (which we assumed earlier remember!), then $$G_K(IV,\perp,C)=\operatorname{HMAC}(K;f_1(IV)\|f_2(C))$$ is a vector PRF as well. For your case imagine $$f_1$$ being the base-64 encoding of IV and $$f_2$$ being the base-64 encoding of the ciphertext prepended by the comma literal.
So first note that because both functions are injective there's never a case when there's two distinct inputs that map to the same output. Because of this all non-repeated inputs to the underlying vector PRF are unique and therefore we always get freshly random outputs making this on a vector PRF as well.

If you might be wondering whether it's safe to assume that HMAC is even a PRF, then note that this is the basic use-case that HMAC was designed for and the entire reason it is a secure MAC.