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.

  • 1
    $\begingroup$ CMAC is defined for arbitrary length strings, so you should just use it on the entire 20 bytes. $\endgroup$
    – otus
    Commented Jul 26, 2014 at 9:46
  • $\begingroup$ 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. $\endgroup$
    – traxonja
    Commented Jul 26, 2014 at 10:17

1 Answer 1


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.

  • $\begingroup$ 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. $\endgroup$
    – traxonja
    Commented Jul 27, 2014 at 16:09
  • $\begingroup$ @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. $\endgroup$
    – otus
    Commented Jul 27, 2014 at 16:24
  • $\begingroup$ 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. $\endgroup$
    – traxonja
    Commented Jul 27, 2014 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.