问有理由不使用XORing对32字节值进行PBKDF2哈希加密吗？

EN

通过这样使用PBKDF2，您真正要做的是将PBKDF2转换为流密码。这一想法的三个主要问题是：

1. 使用PBKDF2作为流密码还没有得到彻底的研究。可能会没事的。或者不是。对PBKDF2的安全特性进行了分析，主要是针对较短的输出，然后只作为KDF进行分析。
2. 如果您重用相同的密码和salt，那么您将得到相同的输出。在流加密XOR与数据模式中，如果加密两个元素，这是非常糟糕的。从这个意义上说，您现在已经将PBKDF2 salt与用于AES的IV合并，从而将需求混为一谈。你最好确保你的整个协议能正确地处理这件事。(从这个意义上讲，这类似于使用PBKDF2生成用于RC4加密的密钥，因为RC4没有IV。)
3. 迭代使PBKDF2变慢。它的处理速度也与请求的输出长度成正比。如果您使用PBKDF2 2/SHA-1并请求，例如，24个字节，并使用10000次迭代，那么您实际上将支付20000次迭代。对于长消息加密，这会很快变得无法容忍。请注意，运行字典攻击的攻击者不需要计算整个流；因此，在让攻击者全速运行的同时，您可能会不必要地降低防御程序的速度。

是。因为已知的-明文攻击，一个可以找到明文的多态者，可以用它来查找哈希来解密不具有明文的密文。

AES是专门为防止攻击者查找密钥而构建的，即使他同时知道明文和密文。

如果您想获得性能并且仍然使用XOR，则可以将随机字符添加到密码中，然后将这些字符包含在消息中。

为了加密M，您生成了一个随机的名N，然后使用: PBKDF2(密码+ N) xor M=C

将NC发送给收件人

NC是通过选择当前密码来解密的，然后接收方提供预共享密码，因此

PBKDF2(密码+ N) xor C= M

要找到用XOR + PBKDF2(密码+A)加密的消息的密钥，并将明文和密文绑定到PBKDF2 (密码+N )，他仍然需要使用普通的蛮力破解PBKDF2。

除了标准的选择--纯文本和密文攻击之外，这个构造没有理由是不安全的。为了防止出现这种情况，您仍然需要一个身份验证机制。(如AES-GCM或Poly-1305)。

作为实际的建筑，我建议你使用抵消。因此，您可以使用PBKDF的前几个位来派生用于身份验证的密钥，其余的作为pad。

然后使用HMAC- the 256对密文进行身份验证并追加标记。

这仅适用于在执行密码派生之前知道数据大小的情况。这就是为什么它没有被广泛使用的原因。

为什么这是安全的？

我在这里跳过身份验证部分，因为这是流密码的标准。

基本上，PBKDF是对HMAC的重复调用，HMAC是一个PRF，所以如果您的salt是随机的(这里是您的IV )，那么输出是伪随机的，并且应该和HMAC一样安全。