我正在使用 RSA 加密服务器和客户端之间的通信。假设我们有 2 个非对称密钥，密钥 1 和密钥 2。
服务器从一开始就有key1（私有），客户端有key1（公共）
所以这里是场景：
据我所知，这应该可以防止中间人攻击，还是我错过了什么？在第 7 点，客户端应该知道是否有人试图给服务器提供错误的密钥来加密，因为除了服务器之外没有其他人可以解密 key2(public)。
如果有什么可以提高安全性的方法，请告诉我。
提高安全性的最佳方法是使用现有设计，而不是尝试重新发明轮子。我不是说你做的事就一定是错的，只是说很多比你我聪明得多的人都花了很多时间思考这个问题。请改用 TLS。
只要 key1 (private) 没有被第三方以某种方式截获，你的场景看起来是安全的。
我想我实际上在一篇论文的某个地方看到了这一点。在其中，Alice 给了 Bob 一个未上锁的盒子（密钥 1 公开），然后 Bob 将一堆他自己的盒子（密钥 2 公开）放入其中，将其锁定并将其发送回 Alice。Alice 然后打开盒子（密钥 1 私人），现在她可以安全地密封 Bob 刚刚给她的盒子。
尽管有盒子类比，但这本质上就是你正在做的事情，所以我会说它是安全的。
不，此协议不安全。
中间人可以拦截客户端发送的数据并将它想要的任何内容发送到服务器，因为您没有为服务器指定任何机制来验证客户端或验证它接收到的消息的完整性。
当然，你可以修改你的协议来解决这些明显的问题，但还有其他问题。如果你把它们都修好了，你就会有一些映射到 TLS 或 SSH 的东西，那么为什么不从那里开始呢？
@Petoj——我关注的问题是服务器信任它收到的消息；您的提案在那里没有提供任何安全保障。但是，如果您担心机密性，您仍然会遇到问题，因为 MITM 可以原封不动地来回传递消息，直到他看到想要查找的内容，因为您对客户端消息没有任何隐私。
您的提议似乎旨在确保来自客户端的消息的完整性。您已经将协议开发到客户端无法区分攻击和网络故障的程度。与其试图帮助客户端确定服务器是否对被篡改的消息采取了行动，不如让服务器在对消息采取行动之前验证消息的完整性。
我同意，只需使用 TLS。
另外，第 5 步到第 7 步提供了什么价值？想要在步骤 1-4 之后进行攻击的 MITM（例如，通过传递 n 个事务然后停止，强制从头开始重试的某种 DoS）也可以在步骤 5-7 之后进行。他们添加了什么？
——马库斯
我同意 Greg 的观点，即您正在重新发明轮子。您本质上描述的是一些基本形式的密钥交换。顺便说一句，为了确保它可以安全地抵御中间人攻击，您还必须确定服务器的身份，即确保客户端可以确定地知道它认为公开的内容（key1）确实是服务器而不是中间人（例如，使用 CA 或将服务器的公共（key1）存储在客户端的安全存储中。）
此外，从系统的角度来看，您还必须注意其他一些注意事项，例如：
key2的会减轻这方面的影响。