[Mono-devel-list] Crypto inconsistency between Mono and MS.NET
jlarimer at gmail.com
Thu Oct 21 14:13:46 EDT 2004
> However I expect that the "official" answer will be like "results of
> calling TransformFinalBlock more than one time is undefined" (i.e.
> expect this to change in future versions but not patched in existing
> In this case Mono and MS implementation will probably keep their
> different behaviors (as I like Mono results much better ;-) unless I (or
> someone else) find a case which leads to serious problems.
I got this reply to my usenet post (below). It seems that it's
intentional. In Mono, ICryptoTransform.CanReuseTransform returns
false, and in Microsoft.NET it returns true, so I guess both
implementations are behaving correctly based on that.
jlarimer at gmail.com
From: Rob Teixeira
Date Posted: 10/21/2004 12:23:00 AM
The behaviour you described is correct. TransformFinalBlock does indeed
reset the feedback.
I believe this is consistent with the intent of the class. The
CanReuseTransform property returns true, which means the feedback should at
some point be reset so the class can be reused.
You have to look at this from the perspective of individual messages. Once
you end a message, you must call TransformFinalBlock, and this resets the
feedback register to the IV for the next message. You have to remember that
message reception may or may not be synchronous, so for example, you can
encrypt various files and they will simply sit somewhere until you decrypt
one of them. You can't assume that you are shipping a bunch of message
around and they will all be dealt with in the same order. If the feedback
isn't reset, that's the only way you could ever decrypt them.
Also, CBC mode induces feedback. This means that subsequent strings of
similar plain text will be affected by previous blocks of cipher text. So,
for example, if you had repeating sets of the letter "E" in your message,
the blocks containing that repetition couldn't be detected from the cipher
text because of the CBC feedback. CBC doesn't guarantee that entirely
similar messages won't look the same after decryption, especially if you are
using the same IV. If you have a scenario like this (where you are sending
the same message over and over using the same IV), you should salt the
message - add a block of random bits to the beginning of the message. On the
receiving end, you can safly ignore the first block, and that guarantees
each message will be different due to the CBC feedback.
More information about the Mono-devel-list