My first idea was to create a 32 bit hash and then encrypt the whole
128+32 bit using the shared key
I take two things from this:
- You have a shared key (and hopefully only two parties).
- You only want to spend 32-bits on authentication (due to hard external limits).
Now the approach you proposed certainly is at least sub-optimal.
Luckily for you, (some) people have fore-seen such constrained deployment scenarios and this is at least part of an appendix of NIST SP 800-38D (Appendix C, PDF) and of NIST SP 800-38C (Appendix B, PDF) and of NIST SP 800-38B (Appendix A, PDF).
If you can (and performance does well), you should use AES-CCM (if you also want privacy) and a standard MAC (such as HMAC or CMAC) otherwise. You can use 32-bit authentication tags, however be sure to read the mentioned sections before doing so, so that you actually understand the involved risks. These 32-bit authentications tags will mean that you only get a message expansion of 32-bit. Note that you still need to somehow supplement a nonce to the scheme (if you use CCM), but this can be a simple packet sequence number or a synchronized counter or something similar, it's only important that both sender and receiver know the value associated with a packet and that these values are unique under a specific key.
What you really want to do is to use ephemeral keys. That is, every 10,000 or so messages you run a pre-shared-key-based key negotiation protocol between the involved parties and use the resulting shared key for the next 10,000 messages. If you want to, you can keep the "master" key and use it for authentication and the ephemeral keys for transport. The details of such a protocol would greatly depend on the number of involved parties. If you re-key regularly (and especially if you hit many decryption errors) you can keep the probability of a successful forgery quite low.
Now to AES-CCM. You really should use the re-key strategy from above here, but also note the discussion in the relevant standard, which states:
$$Tlen\geq\lg(MaxErrs/Risk)$$
That is, the (binary) logarithm of the number of (back-reported) tolerated "invalid" decryptions divided by the maximal risk you are willing to accept for an unwanted message to slip through should be smaller than the length of the authentication tag. So for example if you are going to retry / notify the sender (under the same key!) for up to $2^{10}$ errors, you can still get away with a one-in-a-million chance of a bad message slipping through with 32-bit tags. Note that a re-key resets the "count" for MaxErrs.
If you don't need encryption (that is privacy for the message contents), you also can get away with use CMAC or HMAC which require similar thoughts as CCM does, due to the fact that the probability to successfully forge a message is linear in the number of "yes / no" outputs the adversary gets.