Java邮箱验证加解密BadPaddingException问题及重启适配方案咨询

你遇到的偶发BadPaddingException、前16个字符固定解密失败的问题，和静态IV的安全隐患没有直接因果关系，核心诱因有两个：

• 你大概率用了AES/CBC这类带状态的块加密模式，并且把Cipher实例定义成了静态全局/单例共享对象。CBC模式下Cipher会在加解密过程中持续缓存上一个数据块的运算结果，作为下一个块的运算输入，多线程并发调用同一个实例时，不同请求的块数据会互相污染，直接导致第一个块（AES块大小刚好是16字节，对应你说的前16个字符乱码）解密结果错误，后续块解出的填充字节不符合规范时，就会抛出你看到的BadPadding异常。
• 你对随机IV的使用存在认知误区：IV不需要保密，也不需要单独存储，根本不存在“用了随机IV进程重启就解不开历史令牌”的问题。

不需要额外存储任何加解密元数据，以下方案都可以满足跨重启、跨实例的令牌校验需求，完全符合你无法存储IVSpec的限制，安全强度远高于当前的静态IV+CBC实现：

• 快速修复现有方案：把Cipher实例改成每次加解密时在方法内部新建，不要全局共享，就能立刻解决当前的解密失败、抛异常的功能问题。如果坚持用静态IV，要保证IV长度严格匹配算法块大小（AES要求16字节），不要用长度不符的IV值。
• 对称加密升级方案（推荐）：
  1. 用AES/GCM认证加密模式替代CBC模式，GCM自带密文完整性校验，不会出现CBC模式下填充异常无法定位根因的问题，安全强度更高。
  2. 每次加密时动态生成12字节（GCM标准推荐长度）的随机IV，将IV、认证标签、密文按顺序拼接成完整的令牌字符串下发；解密时先从令牌头部拆出前12字节作为IV，剩余部分传入Cipher解密即可。所有解密需要的信息都包含在令牌本身中，不需要任何外部存储，进程重启、跨服务部署都能正常解密。
  3. 固定密钥存储在环境变量/配置中心，不要硬编码在代码中，密钥长度选16/24/32字节对应AES-128/192/256即可。
• 无加解密场景最优方案：邮箱验证令牌根本不需要做可逆解密，直接用HMAC签名实现即可：
  1. 生成令牌时，把用户邮箱、过期时间戳按固定格式拼接成明文串，用固定密钥计算HMAC-SHA256签名，把明文串+签名拼接成完整的验证链接参数。
  2. 校验时先拆出链接里的邮箱、时间戳，先判断时间戳是否过期，再用相同密钥对明文串计算签名，和链接携带的签名做常量时间比较，两者一致就校验通过。
     这个方案完全没有块对齐、填充、IV相关的坑，性能比对称加密高，实现更简单，也是目前行业内验证类令牌的主流实现方式。

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