AES-128-CBC加解密时IV是否需要随机？Node.js crypto模块使用疑问

基础疑问解答 #

解密时必须传入和加密时完全相同的IV，你看到的「IV需要在加解密过程中保持完全一致」的结论完全正确。AES-CBC模式的加密逻辑是逐块处理的，每一个明文块加密前都会和前一个块的密文做异或运算，第一个明文块没有前序密文，所以需要和IV做异或。解密时第一个密文块也必须用相同的IV做异或才能还原出正确的第一个明文块，后续块的解密依赖前一个密文块，所以IV不一致时只会出现前16字节（AES块大小）损坏、后续内容正常的现象。

问题1解答 #

• IV绝对不能设置为静态值。如果使用静态IV，相同的密钥+相同的明文加密出来的密文永远完全相同，攻击者可以通过密文的重复特征反推明文规律，比如你加密的所有二进制文件头特征一致，密文开头就会有相同的特征段，完全不符合语义安全要求，极易被攻击。
• IV不属于需要保密的敏感信息，它的设计作用就是在密钥固定的前提下，保证相同明文加密出不同的密文，本身不需要加密存储。
• IV可以直接放在有效载荷中，这是工业界的通用做法：加密完成后直接把16字节的IV拼在密文的最前面写入文件即可，不需要额外单独存储。解密时先读取文件前16字节作为IV，剩余内容作为密文解密即可。

问题2解答 #

你对IV安全价值的判断是误解，IV的安全价值远不止保证前16字节的正确性：

1. 静态IV或者可预测IV会让CBC模式面临大量已知攻击，比如选择明文攻击、水合攻击等，攻击者可以在不知道密钥的前提下，通过构造特定明文诱导加密，反推其他加密内容的明文信息。
2. 对于大文件加密场景，静态IV会导致相同文件加密后密文完全一致，攻击者不需要破解密钥，只要通过密文特征就能直接判断你加密的是哪个已知文件，加密的保密性完全失效。

该场景下的最佳实践 #

1. 每次加密都调用crypto.randomBytes(16)生成密码学安全的随机IV，不要使用时间戳、序列号等可预测的内容作为IV，也不要自己实现IV生成逻辑。
2. 加密后将IV直接拼接在密文的最开头，整体写入输出文件即可，不需要对IV做额外加密处理。
3. 解密时先读取文件前16字节作为初始化IV，剩余内容传入crypto.createDecipheriv进行解密。
4. 如果是新开发的业务，更推荐使用AES-GCM模式替代CBC模式：GCM是带认证的加密模式，除了基础加密外还可以校验密文是否被篡改，安全性更高。GCM模式通常使用12字节的随机IV，加密后需要把IV和生成的认证标签分别拼在密文的头部和尾部，解密时先校验标签再解密，避免被篡改的无效内容写入磁盘。

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