[Mono-bugs] [Bug 60573][Nor] Changed - CryptoStream output 1 block short after Flush

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Wed, 23 Jun 2004 10:15:44 -0400 (EDT)


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by t7@pobox.com.

http://bugzilla.ximian.com/show_bug.cgi?id=60573

--- shadow/60573	2004-06-23 09:28:33.000000000 -0400
+++ shadow/60573.tmp.12004	2004-06-23 10:15:44.000000000 -0400
@@ -272,6 +272,34 @@
 used on MS runtime (with MS ICryptoTransform's).
 
 It also seems that the Encryptor and Decryptor have different
 behaviour. Encryptor (like used in this bug report) can process the
 full buffer, while Decryptor (like the failing unit tests) will keep
 the last block for the next round.
+
+------- Additional Comments From t7@pobox.com  2004-06-23 10:15 -------
+Sebastien Pouliot wrote:
+>This is generally not a problem unless you want to access
+>the data _of the last block_ (from the underlying stream) before
+>closing the CryptoStream.
+
+Actually, is it also a problem when trying to use with a NetworkStream
+where you want to carry out a 'conversation'.  For example, my client
+sends a username&password to the server, followed by a Flush, but the
+data is never sent.
+I've also noticed a similar problem on the recieve end - that the
+stream tries to pull an extra block over what was explicitly requested
+via Read().
+My solution was just to wrap the streams at either end in a custom
+Stream that pushes an extra *two* blocks of padding before a Flush()
+and knows how to remove them at the other end.  The first padding
+block gets sent because there is another behind it which doesn't; it
+also satisfies the extra read when the final receiver just requests
+only the data blocks (leaving one padding block in each buffer at
+either end, until more data is sent).
+
+You're right though, that it wouldn't be a problem if I were just
+sending a large stream of data and then closing the stream.
+
+I don't have the MS runtime (or windows) to inviestgate. Thanks for
+looking into it.
+