I intend to authenticate small packets of data, between 16 and 256 bytes each. For some of them encryption will also be required. This will be used on small micro controllers, with RAM sizes ranging in 1 KB to a 64 KB.

My initial approach was to use AES-128 as the base cipher for a block cipher mode with MAC (GCM for instance). However, given the small packet sizes I was wondering if this is secure. So I was considering prefixing to the plaintext, a 32 bit number that is the concatenation of the plaintext CRC16 code and a 16 bit nounce. Then encrypting the result (CRC16 || 16 bit nounce || plaintext) with AEs in block counter mode.

Authentication would be done by decyphering the cyphered packet and validating the CRC16. This approach seems so obvious, but I can't find any implementations of it and I fear that I am overlooking something important.

My question: is encrypting a the CRC together with the packets as secure (meaning as hard to break) as appending a MAC to the packet ?

  • 1
    $\begingroup$ Note: GCM or CMAC has no problem with small packets. $\endgroup$ – poncho May 29 '15 at 22:53
  • $\begingroup$ I know that size does not matter for GCM, although AES-128 only works with 16 byte blocks. I was wondering if using GCM on small packets would be easier to break than using longer, say >= 1 KB, packets $\endgroup$ – ngoncalves May 30 '15 at 12:07
  • $\begingroup$ Nope: actually, GCM is a bit stronger on short packets... $\endgroup$ – poncho May 30 '15 at 13:30
  • $\begingroup$ AES CCM might be a better idea than GCM since it only needs one primitive. GCM is usually implemented with relatively big lookup tables, so it's probably not a good fit for your platform. $\endgroup$ – CodesInChaos May 30 '15 at 18:52

No, in general using a CRC in this way is not secure. A CRC is not designed to be used against adversaries, it is used to detect random bit changes to the data it is protecting (as well as the CRC itself). A CRC of 16 bit will certainly not be as secure as an 8 byte MAC value, that was designed to protect against such attacks. Without additional measures a 16 bit CRC would be pretty easy to brute force.

Note that there are many arguments against authenticate-then-encrypt. One of the reasons that it may be less secure is that it allows attacks on the block cipher mode of operation. In this case the ciphertext may be vulnerable to padding oracle attacks.

| improve this answer | |
  • $\begingroup$ Thanks. I was overlooking that "CRC is not designed to be used against adversaries" and that authenticate-then-encrypt is not recomended. $\endgroup$ – ngoncalves May 30 '15 at 12:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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