ElGamal and Paillier key sizes for short messages
You should not use keys smaller than 1024, and even 1024 is considered too small today. However, if you want additive homomorphism, then you can you encrypt with "ElGamal in the exponent" over Elliptic curves. To explain what I mean by this, let $G$ be the base point (generator) for the Elliptic curve group, let $x$ be the ElGamal private key, and let $P=x\cdot G$ be the ElGamal public key. Then, you can encrypt a value $m$ by computing $(r\cdot G,r\cdot P + m \cdot G)$, where $r$ is random. 

Note that given $(U_1,V_1) = (r\cdot G, r\cdot P + a \cdot G)$ and $(U_2,V_2)=(s\cdot G, s\cdot P + b\cdot G)$, it follows that $(U_1+U_2,V_1+V_2) = ((r+s)\cdot G,(r+s)\cdot P + (a+b)\cdot G)$. Thus, this is additively homomorphic.

The only problem with this scheme is that you cannot efficiently decrypt, since this requires solving the DLOG problem over Elliptic curves. However, if you are only encrypting 4 byte integers, then you can brute force decryption using the private key as follows: given $(U,V)$, for every $a$ check if $V=x\cdot U + a\cdot G$. If yes, then you know that this is an encryption of $a$. Now, this will take $2^{32}$ time which is too long. However, you can use this idea and run a generic DLOG algorithm that takes square-root time (e.g., Pollard's rho algorithm) to do this in time $2^{16}$. It is still expensive, but may be OK for your application (depending on what you want to do).

Using Elliptic curves, the size of your ciphertext can be significantly reduced. E.g., with curve P256, you can hold a ciphertext in just over 512 bits.