我们有一个用 C# 编写的 TCP/IP 套接字服务器，用于将二进制文件传输到客户端。例如，剪辑、图像。带有回调的异步 BeginSend/EndSend 被用于发送 byte[] 缓冲区。
新的要求是加密正在传输的数据。每个客户端连接都将提供一个加密密钥供服务器使用。实际的加密算法并不那么重要，即目标只是确保数据不会以明文形式发送。即使具有 40 位密钥的 RC2CryptoServiceProvider 也足够了……与 RC2 相比，具有 128 位密钥的 RijndaelManaged 是一种过度杀伤而且相当占用 CPU 的资源。
当然可以在传输之前先生成数据文件的加密版本。但理想情况下，我们应该在从文件中读取数据并在套接字上发送时动态加密文件。鉴于数据文件的大小，将整个文件内容读取到内存既不高效也不可扩展。
在动态加密文件中的数据以发送到套接字对等点时，是否有一些好的模式可以遵循？
有几种方法可以实现这一点。这里有一些：
基础设施：与您的客户端建立启用SSL/TLS的VPN。使用新的专用网络连接到您客户的网络。Pro：代码几乎没有变化，具体取决于您当前的实现。缺点：根据您客户的基础架构（以及您的基础架构！），这可能是不可能的。
SSL：在客户端和服务器之间建立直接的安全套接字层连接。优点：易于实施。CodeProject 上有一个关于如何通过 MS SSPI SSL 和 OpenSSL 实现它的示例，您可以将其用作您自己实现的基础；这是链接。缺点：在考虑实施 SSL之前，您应该了解一些众所周知的安全问题。
通用算法（AES、DES、Triple DES、Blowfish）：您可以在通信层发送包之前和接收包之后使用的内部实现。专业版：大量库公开可用，一些自 .NET 3.5 及更高版本起本机可用。缺点：正如你所提到的，有些可能是矫枉过正。
自定义算法：创建自己的！让这些位动摇。优点：它可以随心所欲；公开可用的破解工具几乎没用。这里有一个用于 32 位整数的简单自定义加密协议的示例，很容易适应更大的内容。缺点：公共算法经过彻底测试和验证，并确保您的实现可能无法满足的安全级别；重新发明轮子几乎没有正当理由。
当然，如果您需要额外的安全性（例如通过 SSL 连接的 AES 加密内容），您当然可以混合使用两个或更多，但由您决定。