# Attackability of one-time MAC when using block mode

Consider an encrypted message m which is encrypted with AES-CBC, so in addition to the message there is an IV supplied initially. If I understand correctly the IV and afterwards the prior ciphertext is used, because if wasn't used, a listening attacker could gather information about the secret key s.
We want to add a authentication code (MAC) to the package, however we are quite limited with the amount of bytes we have for the MAC.

Our initial idea was to use s to generate a MAC of length s/2. If this would be used on more than one package could the attacker gain information from it? As far as I understand it's the same problem as using a one-time-pad again and again.

If this is a problem would a possible solution to this be to XOR the message with the IV (or prior ciphertexts) and then generate the MAC with s?

If this doesn't solve the problem, is there any other authentication mechanism we could use, where we can decide the length of the authentication code.

Note: we already spent thoughts on the security of short MACs and don't think it's a problem in our particular scenario.

• The standard approach if you have less than 16 bytes per packet for authentication would be to take a PRF-based MAC (like AES-OMAC or AES-CMAC or keyed Blake{1,2,3} or KMAC or HMAC) and truncate the output to whatever size you have. – SEJPM Jan 23 at 19:20
• I have to admit I'm a bit confused by your question (which is why the previous comment is only tangentially related). Is the construction the all-bold paragraph is suggesting effectively MAC(key,IV XOR Message) or MAC(key, IV XOR Ciphertext) or something different? When you say your MAC is of length s/2 you mean that it's half as long as s and not half the value of s as the length? Also from the question it would appear that you perhaps not realize that a MAC is a function that takes a "message" and a key and outputs a short-ish value that can be used to integrity-check the message? – SEJPM Jan 23 at 20:26
• Can you please describe the attack you have in mind on your proposed simple MAC that would break it on key-reuse? (this would probably help us understand the construction more you're suggesting) – SEJPM Jan 23 at 20:27
• I will try to reformulate the question tomorrow, but your initial comment is already helpful. – Strernd Jan 23 at 21:37