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

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

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

--- 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:
+55-BD-86-26-D2-7B-01-55-64-4A-6C-91-37-F7-C5-15-
+28-A4-87-C2-BF-66-89-E0-E7-8E-85-97-E4-88-63-95-
+62-D1-86-19-11-06-76-58-2D-44-2E-0A-EE-B7-99-FA
+
+Now if I request 32 bytes, then 16 bytes I get:
+55-BD-86-26-D2-7B-01-55-64-4A-6C-91-37-F7-C5-15-
+28-A4-87-C2-BF-66-89-E0-E7-8E-85-97-E4-88-63-95
+
+64-4A-6C-91-37-F7-C5-15-2D-44-2E-0A-EE-B7-99-FA"
+
+"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!
+
+