# Should I calculate two CMACs over two different strings that share common bytes?

I am trying to secure my RF communication in which one RF package consists of two separate segments. I need to make sure that one segment of one packet is not replaced with a valid segment of some previous packet, if you know what I mean.

My RF packet is 32 bytes long, and I need to secure it with CMAC (I found an implementation of AES-128 in CBC mode and CMAC - operating on 16 byte blocks). I am planning on doing it like this:

[B1][B2][B3]...[B30][B31][B32] = bytes in my RF packet

[B1] [B2]... [B10] = first segment (10 bytes long)
[B11][B12]...[B20] = second segment (also 10 bytes long)
[B21][B22]...[B32] = remaining bytes of RF packet contain CMAC of first segment,
and CMAC of second segment (both truncated to first 6 bytes
in order to fit into 32 bytes that I have for one transmission).


Now for the problem: In order to make sure that nobody captures two of my RF packets, and creates third new packet that contain fist segment of packet 1 and second segment of packet 2 (with corresponding CMACs also copied) I am planning on calculating CMAC of first segment + 6 bytes of second segment, and calculating CMAC of second segment by borrowing last 6 bytes of first segment and remaining 10 bytes of second segment.

Should I do this? If not, how can I make sure someone doesn't transmit third custom packet containing two valid segments of my previous transmissions? It would be best if I could somehow calculate CMAC on the entire 20 bytes, but as I know I can only work with 16 byte blocks maximum.

• CMAC is defined for arbitrary length strings, so you should just use it on the entire 20 bytes.
– otus
Jul 26, 2014 at 9:46
• Implementation of CMAC that I have is limited to 16 byte blocks (this is some compact implementation), I will try to find full implementation of CMAC in C language and port to microcontroller. Thanks. Jul 26, 2014 at 10:17

By using 6-byte MACs you can only authenticate about $2^{24}$ messages on average before seeing a collision, which would allow an attacker to swap one message for another. There's a decent chance you'll see one much earlier, so in practice you can only safely use a key for some thousands of packets.

So the best option would be to find an implementation of CMAC (or another secure MAC, like HMAC) that allows you to create a single 12-byte authenticator for the whole 20-byte message.

If you do need to go with the 16-byte CMAC implementation for some reasons, I think including the first MAC as part of the second message is better than overlap, which may be shared between two messages. I.e. calculate the second as $MAC(B[11]...B[20]||MAC(B[1]...B[10]))$. You would still be limited in the number of messages you can send before collision.

• Thanks for the tips. I found implementation of CMAC for messages > 16 bytes (google: KIRK-Engine cmac.c), and I am porting it to my microcontroller. So, with 6 bytes of CMAC I can authenticate only $2^{24}$ messages? I am changing key on each 65536 transmission in my system. I hope that will be enough. Jul 27, 2014 at 16:09
• @traxonja, if you have a MAC of the 20 bytes, you could use the whole 12 bytes for the MAC, in which case you can safely authenticate a larger number of packets.
– otus
Jul 27, 2014 at 16:24
• That is correct, however in my actual RF protocol I have just 6 bytes to spare for MAC. I could reduce PAYLOAD and increase MAC... Anyway, what I have come up with is here: github.com/elektronika-ba/ctrl-rf-protocol I really hope someone could give me a few comments on this protocol idea. Jul 27, 2014 at 17:28