AES256 Network Traffic - How does padding affect size?

I am sending binary data over an AES256 (CBC) encrypted connection that is compressed before it is encrypted. I am using OpenSSL for AES cipher.

The thing is, I need to unencrypt the data in "random" length segments. Does this require padding? And if so, how will I be able to tell the difference between the padding and the real data? Does the 开发者_运维知识库cipher have some built in functionality to detect remove the padding as it decrypts? Should there even be padding in network traffic?

I am trying to avoid someone sending 248 bits of data, and it not being read server side in time, and they see lag (this is for a videogame).

I have googled a lot and found nothing relating to this; which leads be to believe that I may be WAY off on how all this works, or my problem is unique (which I doubt).

What this all boils down to is: Do I have to worry about padding/unpadding the network traffic, or not?

In CBC mode you will need to pad all messages to the next block boundary. You will also need to send an IV with every message. This overhead is obviously more with short messages than with long messages.

CTR mode turns a block cypher into a stream cypher. It does not require padding and the IV is replaced by a Nonce, which can be (but isn't always) shorter than the IV.

If you have a lot of short messages then CTR mode may give you worthwhile saving. Alternatively bundle up a lot of short messages into a single larger message to encrypt.

Padding normally has a very strict form that can be recognised and removed automatically.

You will have the problem that you can only en- and decrypt packages that are in size a multiple of the block size. As I understand your question you would like to have a "realtime" connection with packages that can be smaller or of other size (not a multiple of 128bit). Did think of using a stream cipher instead? Then you can encrypt packages of arbitrary size. You can also use AES as a stream cipher e.g. counter mode.