我们有一个用 C# 编写的 TCP/IP 套接字服务器，用于将二进制文件传输到客户端。例如，剪辑、图像。带有回调的异步 BeginSend/EndSend 被用于发送 byte[] 缓冲区。
新要求是对传输的数据进行加密。每个客户端连接都将提供一个加密 key 供服务器使用。实际的加密算法并不重要，即，目标只是确保数据不以明文形式发送。即使是带有 40 位 key 的 RC2CryptoServiceProvider 也足够了……与 RC2 相比，带有 128 位 key 的 RijndaelManaged 是一种矫枉过正，而且相当占用 CPU。
当然可以在传输数据文件之前先生成加密版本的数据文件。但理想情况下，我们应该在从文件读取数据并在套接字上发送数据时即时加密文件。鉴于数据文件的大小，将整个文件内容读取到内存既不高效也不可扩展。
在动态加密文件中的数据以发送到套接字对等端时，是否有一些好的模式可以遵循？
最佳答案
您可以通过多种方式实现这一目标。这里有一些:
基础设施:与您的客户建立启用SSL/TLS的VPN。使用新的专用网络连接到客户端的网络。 Pro:代码几乎没有变化，具体取决于您当前的实现。 缺点:根据您客户(以及您的!)的基础设施，这可能是不可能的。
SSL:在客户端和服务器之间建立直接的安全套接字层连接。 Pro:易于实现。 CodeProject 上有一个关于如何通过 MS SSPI SSL 和 OpenSSL 实现它的示例，您可以将其用作自己实现的基础； here's the link . 缺点:SSL 有 some well-known security issues在考虑实现之前，您应该了解一下。
常用算法(AES、DES、Triple DES、Blowfish):您可以在通信层发送包之前和接收包之后使用的内部实现。 Pro:公开可用的库负载，some natively available since .NET 3.5 and up .反对意见:正如您提到的，有些人可能矫枉过正。
自定义算法:创建您自己的算法!摇一摇这些位。 Pro:想轻就轻；公开可用的破解工具几乎毫无用处。 There's an example here用于 32 位整数的简单自定义加密协议(protocol)，可轻松适应更大的内容。 缺点:公共(public)算法已经过全面测试和验证，确实确保了您的实现可能达不到的安全级别；重新发明轮子几乎没有正当理由。
当然，如果您需要额外的安全性(例如通过 SSL 连接的 AES 加密内容)，您可以混合使用两种或多种方式，但这由您决定。
关于c# - 在 C#/.Net 中使用异步套接字安全地传输二进制数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18305006/