In low-bandwidth environments, the pipeline is like this: 1) plain data initial stream. 2) compress it. 3) encrypt it or/and sign it. 4) add error-checking

In low-bandwidth environments, the pipeline is like this: 1) plain data initial stream. 2) compress it. 3) encrypt it or/and sign it. 4) add error-checking or even error-correction information. The reason you do encryption (3) after compression (2) is because you don't want encryption to affect the compression rate of the initial stream. If you were to do it in the reverse order (first encryption and then compression) then yes, the resulting message could be bigger.