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

1. 尚未彻底研究将 PBKDF2 用作流密码。可能没问题。或不。PBKDF2 的安全属性已被分析为仅针对大多数短输出，然后仅作为 KDF。

2. 如果您重复使用相同的密码和盐，那么您将获得相同的输出。在流密码 XOR-with-the-data 模式中，如果您加密两个元素，这是非常糟糕的。从这个意义上说，您现在已将 PBKDF2 盐与 AES 的 IV 合并，从而将要求混为一谈。您最好确保您的整体协议正确处理该问题。（从这个意义上说，这类似于使用 PBKDF2 生成 RC4 加密的密钥，因为 RC4 没有 IV。）

3. PBKDF2 因迭代而变慢。碰巧它的处理速度也与请求的输出长度成正比。如果您使用 PBKDF2/SHA-1 并要求，例如 24 个字节，并使用 10000 次迭代，那么您实际上将支付 20000 次迭代的费用。对于要加密的较长消息，这很快就会变得无法容忍。注意到，谁运行字典攻击，攻击者也不会需要计算整个流; 因此，您可能会在让攻击者全速奔跑的同时，不必要地减慢防御者的速度。

是的。由于已知明文攻击，可以找出明文的对手可以使用它来找出散列来解密对手没有明文的密文。

AES 专门用于防止攻击者找出密钥，即使他知道明文和密文。

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

例如，为了加密 M，你生成一个随机数 N。然后你使用：PBKDF2(Password + N) xor M = C

将 NC 发送给收件人

NC通过挑选出nonce来解密，然后接收者提供预共享密码，所以

PBKDF2（密码 + N）xor C = M。

要找出用 XOR + PBKDF2(Password + A) 加密的消息的密钥，并拥有属于 PBKDF2(Password + N) 的明文和密文，他仍然必须使用纯暴力破解 PBKDF2。

除了标准的选择明文和密文攻击之外，没有理由认为这种结构不安全。为了防止那些你仍然需要一个身份验证机制。（如 AES-GCM 或 Poly-1305）。

作为实用的结构，我建议您使用偏移量。因此，您将使用 PBKDF 中的前几位来派生用于身份验证的密钥，其余的作为 pad。
然后，您将使用例如 HMAC-SHA256 来验证密文并附加标签。
这仅适用于您在执行密码派生之前知道数据大小的情况。这就是它没有被广泛使用的原因。

为什么这是安全的？

我在这里跳过身份验证部分，因为这是流密码的标准。
基本上 PBKDF 是对 HMAC 的重复调用，它是一个 PRF，所以如果你的盐是随机的（这里是你的 IV），输出是伪随机的，应该和 HMAC 一样安全。