Security 发送加密数据时，如何抵抗MITM和重放攻击？

假设我与另一台计算机安全地交换了密钥（可能使用Diffie Hellman），下面是我的初步解决方案：

数据包编号+加密数据+消息身份验证码（MAC）

数据包编号是从0开始递增的数字。然后是加密数据本身，然后是两者的MAC。如果有人试图进行MITM攻击，MAC应该无法计算。如果他们尝试重播攻击，接收者将注意到它已经收到了该数据包编号

---

请问我的推理有什么缺陷吗？

< P>你不是在描述中间人攻击，而是重放攻击。 在MITM攻击中，密钥交换被拦截，您说您已经安全地交换了密钥，所以这不是问题所在

---

重播攻击很容易抵御，您可以包括一个唯一的消息ID，然后在接收端检查其唯一性。一般来说，每条消息都有一个到期日期和时间，因此您不需要保存一个不断增加的消息ID列表来进行验证。

我认为您防止重播攻击的方法是合理的。您实际上是在描述一个名为的方法。您的数据包编号是一个“虚拟时间”，收件人使用该时间来验证邮件之前是否未发送

假设我与另一台计算机安全地交换了密钥（可能使用Diffie Hellman）

这是您面临的最大危险——如果中间人能够控制密钥交换（例如，通过与客户端和自身建立一个密钥，与服务器和自身建立另一个密钥），那么MITM可以解密（并重新加密）所有内容。一旦建立了安全密钥交换，就应该不会受到MITM攻击。但难点在于确保密钥交换真正安全

---

有关此信息，请咨询Ferguson和Schneier提供的（或at）。

一旦交换了密钥，第三方就无法拦截或欺骗数据。（除非您的数据包#计数器循环。假设来自旧窗口的数据包可以作为来自新窗口的数据包进行重放。）此问题的解决方案是时间戳（正如其他人所提到的）。不过，如果攻击者能够以某种方式破坏系统时间，这也可能被破坏。（如果他们是中间人，他们可以假想模仿NTP服务器，以这种方式修改客户端的系统时间。）

---

然而，窃听者所能做的是将自己插入双方之间，并扰乱渠道。这可能会导致发生新的密钥交换，这是可以观察到的。为了使密钥交换真正安全，您必须使用第三方验证或只有两个通信者知道的预共享密钥。

是的——通过使用您自己的加密，您可能会冒不必要的风险。我这样做是为了进行教育，因此，请给出具体的评论。另一个主机如何进行自我验证？中间人攻击不仅仅是为了在交换过程中窃取密钥；这是一个过于具体的定义。Wikipedia仅将其定义为任何攻击，在这种攻击中，目标发起人和接收人被强迫相信“他们通过私人连接直接交谈，而实际上整个对话都由攻击者控制”。是的，但是，如果你已经交换了密钥，那么通过谁连接并不重要，只要包是这样做的，中间没有一个可以解密（假设公共/私钥），但它们仍然可以故意破坏数据，因此需要MAC。这取决于加密机制，一些简单地不会解密，因为它们已经在内部有校验和（例如大多数基于块的密码）。但是，通常情况下，如果您包含一个消息哈希，例如SHA256，在加密发生后计算。Eeek，不是大多数。糟糕的我。好的，有一些“有趣”的例子。如果你在搞AES，看看Poly1305 AES作为MAC算法。