会话密钥 + 随机数 = 密钥流？

是的，在数学意义上，密钥流是密钥和随机数的函数（相同的密钥+随机数组合产生相同的密钥流）：

keystream = F(key, nonce)

...F流密码的密钥流生成函数在哪里（通常称为流密码）。可以将其想象F成所有密码学黑魔法发生的黑匣子——每次你向它提供一个密钥和公共随机数时，它都会产生很长的输出，在实践中对于不知道密钥的人来说看起来是随机的，但另一个知道相同密钥的一方可以通过使用相同的密钥+随机数组合简单地重新创建。

密钥流现在是用于加密纯文本的部分？

是的，通过将它们异或在一起：

ciphertext = plaintext XOR keystream

或者，扩展 的定义keystream：

ciphertext = plaintext XOR F(key, nonce)

怎么可能解密任何东西？我是否需要一段纯文本和一条从我建议的纯文本中提取的加密消息，然后派生密钥流？

因为0 XOR x = x和x XOR x = 0所有x，前面的等式意味着这个：

plaintext = ciphertext XOR F(key, nonce)

因此，要解密密文，接收者只需要拥有用于加密它的相同密钥和随机数。再次将想象F成一个紧凑的黑匣子，它在给定用于加密的相同密钥和随机数的情况下再现相同的密钥流。

是否每个数据包都会获得一个新的密钥流进行加密，或者密钥流是否会在全新的 4 次握手后更新？

同一会话中的每个数据包都使用相同的密钥加密，但使用不同的随机数；这意味着在正确的操作中，每个数据包都会使用一个新的密钥流。递增的数据包计数器用于随机数。攻击包括欺骗实现将数据包计数器重置为其初始值而不重置密钥。这会导致受害者使用相同的密钥和随机数加密多条消息，从而使用相同的密钥流。

看看这个维基百科页面。由于我们使用的是所描绘的 CTR 模式的衍生产品，因此计数器的重置是致命的。每个传输的数据包都使用“密钥流”的相同部分进行加密。

因此，既不能通过已知的明文攻击恢复 AES 密钥，也不能立即推导出完整的密钥流。

但是强制使用密钥流的相同（第一）部分（计数器重置为零！）对许多不同的数据包进行加密，我们对密钥流的第一部分进行了已知的明文攻击，并且可能随着时间的推移从中恢复所有位：

1. 解码假设它是一个 TCP 数据包，位于密钥流的第 0 部分（TCP 标头的常量部分）前面几位。
2. 下一个数据包你很幸运：你用已知的密钥流位再次解密数据包，并发现拉丁编码中独立声明文本的开头。这将导致大部分密钥流是已知的。

只是原则 - 我猜仍然不是微不足道的，但足以算作“破碎”。

另请参阅此问题。

除了 user1931751 已经回答的内容之外，我还想就您的第二个问题添加以下内容。

是否每个数据包都会获得一个新的密钥流进行加密，或者密钥流是否会在全新的 4 次握手后更新？

4 次握手派生出一个新的会话密钥，这会导致一个新的密钥流与之前的密钥流不匹配，因为新密钥用于加密（AES 密码的输入）。然而，在针对 4 次握手的 KRACK 攻击中，相同的会话密钥被安装了两次。因此，您将拥有相同的密钥流。但是您要求进行“完整的 4 次握手”，这不是攻击所引发的，所以我会在完整的握手完成后尝试简短地解释一下。

如果安装了一个会话密钥，则用一个初始化的随机数（结合一些固定的东西）将用作加密第一个数据包的 IV（初始化向量）。802.11 标准的这个数据包 (MPDU) 由多个块组成，并且使用 CCM 模式 (RFC 3610) 来解决这个问题。因此，对于 802.11 标准，nonce 是一个计数器，每个数据包都加一。这个由几个 AES 块组成的数据包将使用这个计数器作为其自己的“内部”计数器模式的初始化向量，如 RFC 3610 中指定的那样。因此，每个块和每个数据包都应该在当前密钥流的下一部分下加密，由当前会话密钥和 802.11 初始化向量（由 nonce、MAC 地址等组成的向量）。