C++ 保护通过网络发送的数据的方法？

我刚刚完成了一个应用程序，一个简单的messenger客户端，我希望对所有数据进行加密，无论是3个字母还是200个字母的短语

这类应用的最佳算法是什么？目前，我正试图在VC10上使用3DES和crypto++，但填充和其他事情似乎有点困难

---

我不熟悉密码学，因此欢迎提供任何有用的建议。

我认为RSA会完成这项工作，您可以使用哈希检查数据是否已更改

使用OpenSSL，这是一种经过测试的技术，用于保护传输中的数据，尽管您需要一个受信任的根节点，因此您可能希望进行自签名

之后，您应该询问是否需要将这些消息存储在本地，如果需要，是否需要对它们进行加密。安全要求不同-密码保护的对称密码可能更合适

---

如果您关心的是安全聊天服务，那么您可能关心的是安全匿名聊天服务，在这种情况下，您可能需要了解。

一个重要因素是网络连接的可靠性。如果您不希望有很多丢弃的数据包，或者数据包到达得很晚，那么您可以在链接模式下使用流密码或对称分组密码。如果您希望网络更不可靠，那么ECB模式下的对称分组密码将更合适，因为丢失的数据将只是丢失的数据，不会使整个事情失去同步。您希望用一些随机数据填充每个明文块；e、 例如，如果每个数据块为64位，则最多生成该数据的32位，其余数据为随机数据。这样，如果相同的数据被多次发送，就不明显了

一般来说，PKC不用于加密消息。它用于加密随机会话密钥，然后与快速对称算法（如3DES、AES或Blowfish）一起使用。

首先，使用3DES的唯一原因几乎是与已经使用3DES的其他软件兼容，并且不支持任何更新的软件。3DES基本上是一种快速的黑客攻击，允许预先存在的DES实现（尤其是在硬件中）继续使用，直到它们被替换——但总体而言，这是一个相当糟糕的选择。DES的真正设计目的是在软硬件中实现，它需要大量的CPU时间来实现安全性

第二，你还没有告诉我们足够的情况，给我们一个真正的答案。您所说的是一个基本封闭的系统，您可以预先将密钥共享给用户，或者通过一些带外方式获取密钥，例如，给他们打电话，就密钥达成一致，然后他们就可以使用密钥，而无需再打电话了？或者，您是否需要能够接受任意用户而无需手动设置更复杂？用户是否需要某种方式来验证服务器的身份，或者您是否希望他们只相信响应正确URL的任何服务器都将是正确的服务器，添加这种验证会增加更多的复杂性

为了便于讨论，我们假设您需要加密而不是身份验证，即不需要验证与正确服务器的连接。在这种情况下，我会从选择AES开始，AES是众所周知的、容易获得的、经过大量研究的，而且就公众所知，是非常安全的

从那里，您需要选择一个键。一种典型的方法是使用一些公钥协议（例如RSA）来交换密钥。一种可能的方法是客户端将其公钥发送到服务器。服务器生成一个会话密钥，只是一个大小合适的随机数，用作加密密钥，使用客户端的公钥对其进行加密，并将结果发送回客户端。对于该会话的其余部分，使用对称协议（例如，AES）使用该会话密钥对两者之间交换的所有数据进行加密

至于如何生成随机数：不要使用rand或任何关于该顺序的东西。通常的方法是在所谓的计数器模式下使用相同的加密算法AES-您只需保留一个计数器，并创建一个密钥，然后在内部增加一个计数器，使用一些密钥对其进行加密，并将结果用作会话密钥

由于其他人已经提到了加密的操作模式，我也将在这一点上花上我的两分钱：除非你真的期望一个可怕的嘈杂连接，否则你可能不想使用ECB，而且接收者获取所有可能的数据非常关键，即使有向攻击者暴露数据的风险

---

CBC只有一种明显的可能性，它的自同步能力几乎与从丢失的数据包中恢复的能力一样好，因此传输中的突发噪声可以破坏两个数据包，而不是ECB中的一个数据包，但是要隐藏数据以防攻击者，这需要做得更多。

它的安全性必须有多高？就好像需要一百万美元。然后使用TLS，这是保护pr的行业标准

---

耳镜，但没那么容易。如果你想让事情变得简单，你可以使用SSH隧道，但它更多的是用来修复不支持加密的协议，而不是用来为你正在设计的协议添加安全性。要获得真正权威的答案，你可以尝试crypto.SE或security。设置重要部分：不要试图发明你自己的协议，使用现有的。使用TLS。SSH也可以工作，但对于类似messenger的应用程序来说，它似乎不是正确的选择。如果攻击者可以更改数据，则哈希值也可能会更改。不需要增加复杂性，除非它确实为您带来了一些好处。RSA通常不是加密消息数据的合适工具。它最适合用于协商对称密钥，仅此而已。如果您通过可靠的协议（如TCP/IP）运行它，为什么不呢？那你就不用担心了。此外，性能与小消息无关。谢谢你的回答，非常有帮助。是的，我使用TCP/IP协议。1，但是，正如@斯普拉夫所说，如果他在TCP上运行，丢失的包应该已经被传输层处理了。@ Matteo：非常正确。但是对于聊天应用程序，我认为在某个时候，他可能希望至少尝试使用像UDP这样的东西来减少等待时间……你是完全正确的，我写这篇文章只是因为他在某个地方写到他的协议已经在TCP上运行了。根据OP的保护意味着什么，然后使用HMAC来防止传输中的数据被篡改也可能是个好主意。