If we use standard encryption algorithms, the message size will be increased tremendously to hundreds of bytes" - what do you base that on? (and what are
standard encryption algorithms).
AES is a fairly standard encryption algorithm which is supported by, for instance, the ESP32, which is a very widely used board .
This page says
Most symmetric ciphers work on blocks of data considerably larger than a single byte (AES-128, for example, works 16 bytes at a time). As a result, if the file isn't a multiple of the block size, you need to pad the end to fill a complete block. There are ways (such as "ciphertext stealing") to do this without making the encrypted file larger than the original file, but just adding a few bytes of padding is usually simpler.
so, you may have a concern with message size < 16 bytes.
If so, you have to ask yourself if you can't buffer your data and send it when you have 16 bytes.
A Basic Introduction to BLE Security says
The way that BLE overcomes this is by encrypting the data being transferred using AES-CCM cryptography.
So you probably don't need to encrypt on chip, unless you are buffering data (or want double encryption).
It would help us if you can define exactly what size of data you are sending, how often, and how time sensitive is it (can you buffer it)?
Maximizing BLE Throughput Part 3: Data Length Extension (DLE) might be of help if you use BLE 5. To quote ...
DLE is a feature added to the Link Layer that allows the Data Channel Protocol Data Unit (PDU) Payload field to be increased from the default 27 bytes to up to 251 bytes
In short, I think that BLE 5 can solve your problems. What do you think?