浏览器中PBKDF2生成AES密钥的盐值来源与使用方案咨询

核心结论 #

• 绝对不要用密码哈希当盐，这完全违背盐的设计初衷，会大幅削弱PBKDF2的安全优势。
• 生成随机盐并附加到加密内容头部是行业标准且安全的方案，能完美解决跨浏览器/后续解密的密钥匹配问题。

为什么不能用密码哈希做盐？ #

盐的核心作用是避免相同密码生成相同密钥，防止攻击者用彩虹表批量破解。如果用密码的SHA256哈希当盐，相同密码的哈希值是固定的——等于所有用同一密码加密的文件都共用同一个盐，攻击者只需针对这个固定盐制作一次彩虹表，就能破解所有对应加密文件，这和你之前直接用SHA256生成密钥的安全性没区别，等于白换了PBKDF2。

随机盐+头部附加的具体实现思路 #

这是成熟可靠的方案，步骤清晰：

1. 加密流程：

   • 用浏览器原生的crypto.getRandomValues()生成16字节以上的随机盐（长度足够才能保证随机性）。
   • 同样生成随机IV（初始化向量，AES-CBC/GCM模式都需要，推荐16字节）。
   • 调用crypto.pbkdf2()，传入密码、盐、足够的迭代次数（建议100000次以上，可根据浏览器性能调整）、密钥长度（比如32字节对应AES-256）、哈希算法（推荐SHA-256），生成AES密钥。
   • 用生成的密钥和IV加密文件内容。
   • 按固定顺序将盐、IV（如果用AES-GCM模式还要加认证标签）拼接在加密内容最前面，比如：[盐(16字节)] + [IV(16字节)] + [加密内容]。
   • 将拼接后的整体作为下载文件输出。

2. 解密流程：

   • 读取下载的文件，按加密时的固定长度从头部提取盐和IV。
   • 用相同的密码、提取到的盐，搭配一致的PBKDF2参数（迭代次数、密钥长度、哈希算法）生成密钥。
   • 用生成的密钥和IV解密后续的加密内容。

额外注意事项 #

• 盐不需要保密，只要保证每个加密文件的盐随机唯一即可，放在文件头部完全安全。
• 迭代次数不能过低，PBKDF2的安全性很大程度依赖迭代次数，太低易被暴力破解，太高会导致浏览器卡顿，建议在100000-500000区间测试平衡。
• 优先使用AES-GCM模式，它自带内容认证功能，能防止加密内容被篡改，安全性优于CBC模式。

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