salt - 在基于密码的加密中使用密码盐作为 IV

Question

我需要编写一个简化的加密 API，它可以通过使用随机生成的 key 或密码派生的 key 轻松处理对称加密。

密码生成是使用 OpenSSL 库中的 PKCS5_PBKDF2_HMAC() 函数并使用 EVP_sha256() 作为哈希算法和随机生成的 16 字节盐来执行的。

对称加密是使用 OpenSSL EVP API 执行的。

我的问题是:将密码派生盐也用作加密的 IV 有多(不)安全？

这个问题背后的原因是，这将允许我以下列方式简化 API 和输出流:

• 对于加密例程，用户必须提供密码或 key ；根据提供的任何一个，代码可以决定是否需要从密码中派生 key 或按原样使用提供的 key ；
• 类似地，对于解密例程，用户必须提供密码或 key ；根据提供的任何一个， key 可以从密码和 IV 中重新导出，它也充当密码盐(并且放在输出流中的第一位，就在密文之前)；
• 输出流将仅包含与密文连接的 IV，消除了单独的盐；
• 对于随机生成的 key 或密码派生的 key ，输出流将是相同的。

注意:API 会自动处理 salt/IV 生成，这是为每个加密 session 随机生成的，因此即使重复使用密码，也保证 key 是不同的。

预先感谢您的回答。

Answer 1

碰巧的是，我在处理我自己的一个项目时遇到了几乎完全相同的场景(其中一条消息在 CBC 模式下使用随机 IV 加密，用户可以指定一个 key 或文本密码)。

类似问题讨论here和 here .总结一下:IV 的目的是确保即使 key 被重复使用，密文也保持唯一。只要您像您所说的那样为每条消息生成一个新的 IV， key 的来源就无关紧要。这意味着你可能安全地重复使用盐作为 IV，就目前任何人所知。它甚至看起来甚至没有意义成为一个问题，因为在以不同的方式派生 key 之前，盐会通过加密散列；只要您在 PBKDF2 中使用良好的哈希函数(即上面提到的 SHA-256)，这样派生的 key 就无法与随机生成的 key 区分开来，在这种情况下可能是随机生成的。

但是，人们总是在密码分析的世界中发现意想不到的事情，即使我们不知道，直接在两个地方重复使用相同的数据在原则上也被认为是一件坏事任何实际问题就在这一刻。你真的应该为此担心吗？以我对密码分析的知识水平，我介于“也许”和“我不知道”之间，这对我的口味来说有点太不确定了，所以我将采用“技术上更安全”的行动方案，它生成单独的 IV 和盐值。 Transmitting both the salt and the IV is a perfectly cromulent security practice ，如果用户直接输入 key 并且盐未被使用，您也不会有任何损失。