问题
I only found this question answered:
Size of data after AES/CBC and AES/ECB encryption
Since AES adds padding to the end of an encrypted message, there is a simple formula to determine the expected output length, given the input length. However, is there any way to determine what is the expected size of the DECRYPTED message? And if there isn't, should I just send it along with the iv and the encrypted message?
回答1:
AES is a block cipher. Block ciphers only encrypt blocks, in case of AES, blocks of 128 bits / 16 bytes. To use a block cipher for larger amounts of data you need a mode of operation. There are modes of operation such as AES-CBC and the insecure AES-ECB that do require padding, as they encrypt/decrypt per block as well. For AES you can be certain that the amount of padding is 1 to 16 bytes even before decryption.
Other modes such as AES-CFB, AES-OFB and most importantly AES-CTR don't require padding. These modes simply create a ciphertext as large as the plaintext (although you may still need a static amount of overhead to send the IV vector if you cannot calculate it). AES-GCM is a mode that also uses CTR internally but also adds an authentication tag to protect the integrity and authenticity of the message.
It's absolutely OK to send the length of the plaintext with the message if you want to know the size before decryption. If you want to protect the integrity of the message, you should however include those values in the authentication tag.
If you have a choice it is probably easier to simply go for CTR or GCM mode encryption.
Note that there is also a method called ciphertext stealing for CBC. CTS is however not available very often. It can remove the padding for larger ciphertexts, but you would still be left with the IV as overhead.
来源：https://stackoverflow.com/questions/27603209/size-of-data-after-aes-decryption