MbedTls AES-GCM原地解密：输出缓冲区长度及8字节额外空间疑问

解密后输出与输入缓冲区长度是否相同？ #

根据MbedTls官方文档明确说明：length参数既是待解密密文的长度，同时也是解密后明文的长度。因此解密完成后，输出缓冲区的有效明文数据长度和输入密文长度完全一致。

解密时为何需要至少8字节的尾随额外空间？ #

这是由GCM模式的内部实现逻辑决定的：mbedtls_gcm_auth_decrypt底层依赖mbedtls_gcm_update等函数处理数据，这些函数会使用临时中间缓存。当输入输出缓冲区重叠（原地解密场景）时，如果输出缓冲区没有足够的尾随额外空间，中间数据的写入操作可能会覆盖尚未处理的输入密文数据，导致解密逻辑出错。文档要求“输出缓冲区至少落后输入缓冲区8字节”，本质是为了规避这种数据覆盖风险。

核心疑问解答 #

• 8字节额外空间是否仅解密过程中需要，完成后无需保留？
  是的。该额外空间仅作为解密过程中的临时操作缓存，当解密完成且标签验证通过后，最终的明文数据只会占用与原密文长度相同的空间，额外的8字节不会被写入有效明文内容。因此外部可以复用同一缓冲区，只需保证解密执行期间缓冲区有足够的临时空间即可。

• 当前8字节要求是否仍适用？实测无额外空间也能正常运行？
  实测正常属于特定场景下的巧合：比如密文长度恰好是AES块大小（16字节）的整数倍，或者当前版本的内部缓存逻辑在该长度下未触发数据覆盖。但从官方规范和稳定性角度，必须严格遵守8字节的空间要求——一旦遇到非对齐的密文长度，或是后续MbedTls版本调整内部实现，无额外空间的原地解密极可能出现数据损坏、解密失败甚至内存越界的问题。此外，当标签验证不通过时，函数会调用mbedtls_platform_zeroize清空输出缓冲区（原地解密场景下即输入缓冲区），空间不足也可能引发内存错误。

补充函数内部逻辑 #

mbedtls_gcm_auth_decrypt的完整函数签名：

int mbedtls_gcm_auth_decrypt(mbedtls_gcm_context *ctx, size_t length, const unsigned char *iv, size_t iv_len, const unsigned char *add, size_t add_len, const unsigned char *tag, size_t tag_len, const unsigned char *input, unsigned char *output)

它并不直接执行解密，而是通过以下调用链完成操作：
mbedtls_gcm_auth_decrypt → mbedtls_gcm_crypt_and_tag → mbedtls_gcm_starts、mbedtls_gcm_update_ad、mbedtls_gcm_update、mbedtls_gcm_finish
若标签验证不匹配，函数会调用mbedtls_platform_zeroize清空输出缓冲区（原地解密场景下即输入缓冲区）。

内容的提问来源于stack exchange，提问作者dfmg