[Mono-bugs] [Bug 69036][Nor] Changed - PasswordDeriveBytes results differ from Microsoft when used in non-PKCS5 compliant mode

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Sun Feb 25 00:46:27 EST 2007

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 peter.dettman at iinet.net.au.


--- shadow/69036	2004-11-09 11:26:07.000000000 -0500
+++ shadow/69036.tmp.24581	2007-02-25 00:46:27.000000000 -0500
@@ -214,6 +214,32 @@
 This is a bug in MS implementation. It should be fixed in Whidbey beta 2. 
 Note: Mono will keep the "expected" behaviour across all versions
 (anyway I've no idea how to reproduce the bug ;-) so results can
 sometimes be different between Mono/MS. Stick to strict PKCS#5 to
 ensure compatibility.
+------- Additional Comments From peter.dettman at iinet.net.au  2007-02-25 00:46 -------
+This same issue came up on the Bouncy Castle mailing list recently. I 
+want to point out something about the 48 vs 32/16 example above:
+"Even MS implementation is kind of strange, like iff I request 48 
+bytes in one short I get:
+Now if I request 32 bytes, then 16 bytes I get:
+"The second GetBytes (16) starts with the 8 previous bytes ***and does
+"something fishy" with them***"
+Actually, those 8 "fishy" bytes are bytes 9-16 of the GetBytes(32), 
+so it's worse than just being a mysterious algorithm, it's repeating 
+the output. If this is your key/IV, the IV now contains 8 bytes of 
+your key!

More information about the mono-bugs mailing list