在同一个CryptoStream上使用BinaryReader和BinaryWriter时，如何避免超时？

Question

我有一个程序使用BinaryReader和BinaryWriter通过网络发送字符串 ， int和byte []消息。

消息的顺序和内容对于服务器和客户端上的执行流程都很重要，但持续时间从不长。

现在我正在尝试加密一切。

这是我在实际代码周围的新包装器：

using encReaderStream = CryptoStream(clientStream, myAES.CreateDecryptor(), CryptoStreamMode.Read),\
      encWriterStream = CryptoStream(clientStream, myAES.CreateEncryptor(), CryptoStreamMode.Write),\
      enc_reader = BinaryReader(encReaderStream),\
      enc_writer = BinaryWriter(encWriterStream):
          ....

这个例子是boo代码，但在这个例子中它应该直观地等同于C＃。

现在发生的是服务器使用enc_reader.ReadString()正确获取第一个加密消息，并使用enc_writer.Write("Accepted")回答。 但客户永远不会得到答案。

我已经测试了消息的顺序是否重要，而且确实如此。 如果我开始从服务器发送一个字符串，然后客户端获取它，但如果我继续发送消息，我将很快陷入相同的情况。

我有一点认为CryptoStream可能负责不与BinaryReader / BinaryWriter合作，但我不知道如何以一种好的方式解决这个混乱。

我的服务器有很多功能，只需要BinaryReader和BinaryWriter ，如果它们可以像以前一样工作，那将是非常方便的。

编辑：

我还在这里用一个小的C＃项目复制了这个情况，使用了提到的CTR模式的AES实现。

Answer 1

您无法在块的中间刷新块密码，因为从算法的角度来看，这些字节尚未就绪。 他们没有下定决心。

可能最好的解决方法是使用流密码。 .NET内置支持很差。 在计数器模式下拉入实现AES的库。

请注意，如果不使用经过身份验证的加密（并且它看起来不像你那样），攻击者可以编辑数据，尽管他们无法读取数据。 使用AES-GCM缓解。

---

后来我们发现您使用的CTR模式库已损坏。 用这个：

public int InputBlockSize { get { return 1; } }
public int OutputBlockSize { get { return 1; } }