1

I have a client/server setup with CryptoStream around TcpClient's NetWorkStream on both ends. Communication works great biderectionally when I read from the NetworkStream directly but with CryptoStream I can't read a single block of available data. I am closing the CryptoStream to cause FlushLastBlock to be called from the server and indeed the one and only block of 16 bytes (AES encrypted) shows up at the client end. So why does CryptoStream.Read() block waiting for data when there is a full block of data available?

P.S. I've verified that sending an additional block allows the reader to read the first block. Is this just a bug or by design?

snort
  • 2,285
  • 3
  • 19
  • 21

1 Answers1

0

Have you called FlushFinalBlock() on the CryptoStream on the sending side?

using (var stream = new MemoryStream())
{
    using (var cs = new CryptoStream(stream, your_encryptor, CryptoStreamMode.Write))
    {
        your_formatter.Serialize(cs, your_graph);
        cs.FlushFinalBlock();
        your_socket.Send(stream.GetBuffer(), 0, (int)stream.Length);
    }
}
Brett
  • 51
  • 3
  • Yes, or rather I dispose the stream writer which ends up calling FlushFinalBlock() and does push the one and only block to the client. – snort Dec 19 '13 at 05:06
  • Right. But when and how do you dispose the stream writer? Because if it waits for the reader to read the final block, you may have a chicken and egg problem. Now it is the turkey season, but... – Maarten Bodewes Dec 19 '13 at 17:02
  • How have you verified that "there is a full block of data available"?, (a wireshark capture?) and how are you calling read? – Brett Dec 19 '13 at 22:54