WhatsApp部分媒体解密失败排查：渐进式JPEG常出错

问题背景 #

调试WhatsApp Cloud API加密媒体下载功能时，出现特定文件异常：下载的.enc文件SHA256与encrypted_hash完全匹配，但HMAC验证失败、AES-256-CBC解密因无效填充报错，且该问题在特定文件上持续出现。正常流程为：下载加密媒体→验证SHA256与encrypted_hash一致→验证截断HMAC-SHA256（10字节）→AES-256-CBC解密→验证SHA256与plaintext_hash一致，多数文件可正常执行。

疑问1：此情况是否必然是元数据不匹配导致？ #

不是必然，但大概率是元数据问题。因为文件SHA256匹配已证明下载的加密文件完全正确，故障仅出现在解密依赖的元数据环节，常见诱因包括：

• 元数据串用：将不同文件的AES密钥、IV、HMAC密钥交叉混用
• 编码/解码错误：Base64解码元数据时使用错误字符集，或出现字节截断、多取
• 字段映射错误：混淆AES密钥与HMAC密钥的用途，或错误使用其他无关元数据字段

疑问2：WhatsApp是否存在特殊的HMAC/解密布局？ #

Meta官方文档定义的布局是标准格式，但需注意几个易踩坑的细节：

• 加密文件结构为：[加密内容] + [10字节截断HMAC]，HMAC计算的输入是不含末尾10字节的加密内容，且需使用独立的HMAC密钥（而非AES密钥）
• AES-256-CBC的IV固定为16字节，必须严格从Webhook元数据中获取，不可使用默认值或其他字段替代
• 密钥长度要求：AES-256密钥为32字节，HMAC-SHA256密钥也为32字节，若密钥长度不符会直接导致解密或HMAC验证失败

疑问3：渐进式JPEG与基线JPEG的加密处理是否存在差异？ #

官方未定义两种JPEG格式的加密逻辑差异，加密是针对文件原始字节的全量处理，与内容格式无关。若出现相关异常，可能是间接因素导致：

• 渐进式JPEG的字节结构与基线不同，但不会影响加密/解密的核心逻辑
• 若解密后验证plaintext_hash失败，需排查是否有后续流程自动转换JPEG格式，但你当前问题出在解密阶段，与JPEG格式本身无关

额外排查建议 #

• 对比失败文件与正常文件的元数据（AES密钥、IV、HMAC密钥），检查Base64解码后的字节长度、内容是否符合要求
• 用openssl命令手动复现解密流程（需先移除加密文件末尾10字节HMAC）：

  # 先截取加密内容（去掉最后10字节）
  head -c -10 downloaded_file.enc > encrypted_content.bin
  # 执行解密
  openssl enc -d -aes-256-cbc -iv [IV_HEX] -K [AES_KEY_HEX] -in encrypted_content.bin -out decrypted_file
  

• 手动计算HMAC验证：用HMAC密钥对encrypted_content.bin计算SHA256，取前10字节与原文件末尾10字节对比

内容的提问来源于stack exchange，提问作者Pedro Henrique Segatti