使用aes-256-cbc加密文件夹时密码变更无法解密问题求解

核心思路为密钥分层管理，避免直接用用户密码作为加密文件的工作密钥，以下为可直接落地的实现方案：

方案1：DEK/KEK分离架构（行业标准首选） #

• 首次生成加密文件时，单独随机生成256位的*数据加密密钥（DEK）*和128位的CBC模式IV，使用该DEK+IV完成zip文件的AES-256-CBC加密。
• 从用户登录密码派生密钥加密密钥（KEK），派生过程使用PBKDF2WithHmacSHA256算法，配置不低于10万次的迭代次数+随机生成的盐值，盐值明文存储在本地元数据中即可无需保密。
• 用KEK加密明文DEK和IV，将加密后的DEK、IV、PBKDF2盐值、迭代次数作为元数据，存储在加密zip文件的固定头部，或者单独存储在本地对应加密文件的元数据记录中。
• 用户修改密码时，仅需执行以下操作：用旧密码派生旧KEK解密拿到明文DEK，再用新密码派生新KEK重新加密DEK和IV，替换原有元数据即可，完全不需要修改已加密的zip文件内容，多大体积的加密文件都可以秒级完成密码修改。

方案2：密码版本兼容方案（最小化改动现有逻辑） #

如果不想调整现有加密流程，可以做本地密码版本映射：

• 本地存储加密文件时，同步绑定该文件加密时对应的密码版本号，以及该版本密码派生密钥的加密副本（副本用当前生效的最新密码加密存储）。
• 用户修改密码时，将所有历史版本的密钥用新密码重新加密后存储，解密时先读取文件对应的密码版本号，匹配到对应密钥再执行解密即可。

注意：该方案会积累大量历史密钥，密码修改次数越多安全风险越高，仅适合临时过渡使用。

现有流程优化建议 #

• AES-256-CBC模式本身不提供完整性校验，建议加密后同步计算HMAC-SHA256校验值存储在元数据中，解密前先做校验，避免比特翻转攻击或文件损坏导致的异常。
• 打包zip时建议保留文件权限、创建/修改时间等元数据，避免解密后文件属性丢失。

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