AES reversing

[skater-boy]

I'm testing with tiny-AES-c and I now have a question which is related to AES in general.
Sorry I'm note sure if I can ask this kind of question here. If this wasn't the right place, please just /ignore my question and close it.
The question: if someone want to attack some AES-CBC encripted data to gain the key, does they have any advantage if both a CRC32 of the original (plain) data is available along with CRC polynomial used?
Thanks

[Jonas-July]

If an attacker wanted to get the key, I don't think they have an advantage with the CRC code.

On the other hand, if your message is of low entropy (i.e. only a limited number of possibilities), then the attacker could just try all of them and check against the CRC. In that sense, the attacker doesn't even need the key. This is not unique to CBC or AES, that's the case with every cipher.

I'm not sure what you are trying to achieve. A single bit error in the ciphertext will lead to random garbage after decryption, so CRC is of no use. If you want to correct errors during transmission, then use the CRC algorithm on the ciphertext.
If you want to ensure integrity, i.e. that noone has tampered with the message, then either use a message authentication code (MAC) or better yet, use an explicit AEAD cipher.

To conclude, I'd recommend that you ask these sorts of questions on stackoverflow. There are more experts there and your question can be found easier than in an issue on github.
Cheers

[kokke]

@Jonas-July has really answered this brilliantly. Thanks for the help 😃👍

@skater-boy If you provide the CRC32 checksum of the unencrypted message, you are definitely leaking information (about the unencrypted message). It may still be infeasible to guess the AES key though.

As Jonas says, depending on the complexity (total entropy) of the plain-text message, it can be trivial to guess the message from the CRC32.

It is indeed more usual to do the checksum over the encrypted data or to use an authentication code (MAC/signature) or use AEAD.

Bruce Schneier's book Cryptography Engineering has a lot of practical tips on how to create secure protocols.

I second the recommendation of stackoverflow.com

EDIT:

I want to add that the Schneier book is easily readable and assumes no previous knowledge of cryptography.

[skater-boy]

@Jonas-July
@kokke
First thing, thank you for your help.

This is why I use the plain-data's crc instead of the encrypted-data'crc.
The message is the encrypted firmware-update sent from a PC to the micro-controller. I use AES-CBC-192.
In order to go with a crc32 of the encrypted data, the micro-controller should have enough memory to store temporary all the new firmware (encrypted) and then process this new firmware only if it has a valid crc.
But in my case I have no storage memory big enough to store all the firmware data.
So I decrypt the incoming encrypted-firmware on the fly and I write the plain data directly over the old application firmware. This job is done by the bootloader, of course.
At the end of the process I read back the written data from micro-controller's internal-flash and I calculate the crc32.
If this crc is OK I get 2 green flags: 1. all the received encrypted data was good and 2. the data written on the micro-controller's application area is good.