If I use AES_GCM for encrypting my data, I understand I don't need to worry about padding.
Right.
If my data is 22 bytes, I would be getting a 22 bytes encrypted output.
That's not accounting for the Initialisation Vector. The usual size of that is 12 bytes, usually as a header of the ciphertext. You can reduce it's size (and have the receiver pad with zeroes), but it must remain wide enough that IV won't be reused. That can be a counter. If the payload has fields that need not be encrypted and change at each use (e.g. time guaranteed monotonic because it survives reset), they can be safely used as IV (and removed from what's encrypted).
The value of this tag field is recommended to be minimum of 32 bytes
No. The tag field is a maximum of 16 bytes (128 bits). Reducing it to 4 bytes (32 bits) is OK in some applications. If the tag is $b$-bit, making $n$ attempts at getting a bogus message accepted by a verification device will result in one being accepted with probability no more than $n/2^b$. For example, with a 4-byte tag, if adversaries submit one message per millisecond for one day, their probability of success is 2%.
There's no a hard limit to the minimum tag size (unless enforced by some API). If you reduce it to 2 bytes, adversaries that submit one message per second for one hour have probability of success 5.5%. If your accepting device locks after a small number of errors, that might be acceptable (but that's at the expense of availability/resistance to denial of service).
Other option would be to use CRC16
No! Do not use AES-CTR (or equivalently AES-GCM without tag) on data protected by a CRC16: adversaries that got hold of one message can alter it into another message that will be accepted, in a basic attack exploiting the linearity of CRC and CTR encryption.
My key/IV pair keep changing every 1 hr
Don't do this if you encrypt more often than once per hour! A key/IV pair must not be reused. AES-GCM (and AES-CTR) are extremely vulnerable to that. It's even in theory not recommendable to reuse an IV if the AES key is 128-bit, for it allows multi-target attack.
Again, you must figure out a way to have the IV change at each encryption, at least if the same key is reused. The two most standard ways to do it are:
- A wide random IV (the standard is 12 bytes), which you won't like.
- Using AES-GCM-SIV, but overhead is even worse.
- A dedicated counter, which can be narrower (e.g. 2 bytes), but must be such that it won't repeat (for a given key). Things to be considered include ability for adversaries to reset the device/counter, or make it overflow and cycle.
- Using some field of the data that needs not be encrypted and naturally changes and does not repeat (for a given key). That's your best bet I guess.
You might also be able to save some space by using a better encoding of the data before encryption. For example, 12 decimal digits fit 5 bytes.
