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

[bugzilla-daemon@bugzilla.ximian.com]

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 sebastien@ximian.com.

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

--- shadow/60573	2004-06-23 10:15:44.000000000 -0400
+++ shadow/60573.tmp.12499	2004-06-23 10:37:56.000000000 -0400
@@ -300,6 +300,36 @@
 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.
 
+
+------- Additional Comments From sebastien@ximian.com  2004-06-23 10:37 -------
+> 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.
+
+That's what I meant by accessing the last block. Conversation-type
+applications are more difficult when using block ciphers (at least
+with traditional cipher modes). In this case a stream cipher, like
+RC4, is much easier to use (in fact too much easier, which often lead
+to other security problems).
+
+> 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().
+
+This one may be a padding issue (i.e. normal). Encrypting a 64 bytes
+(8 blocks of 8 bytes) will result in in a total of 72 bytes (because
+be default PKCS7 padding is used, which adds an additional block if
+the last block is complete). So if you Read 64 bytes of data using
+CryptoStream then the underlying Stream will be read for 72 bytes (and
+block if the last block isn't available).
+
+Note that if your application ensure 8 bytes blocks you can use
+PaddingMode.None (but this may be dangerous if you change cipher in
+the future as the block size can vary).
+
+If this isn't a padding issue I would appreciate a (as small as
+possible) test case for the Read. Thanks