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

[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=69036

--- shadow/69036	2004-11-02 17:44:30.000000000 -0500
+++ shadow/69036.tmp.5612	2004-11-03 11:36:55.000000000 -0500
@@ -11,13 +11,13 @@
 AssignedTo: sebastien@ximian.com                            
 ReportedBy: gonzaloantonio@gmail.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
 URL: 
 Cc: 
-Summary: An System.ArgumentException appears when execute any assembly that use PasswordDeriveBytes class
+Summary: PasswordDeriveBytes results differ from Microsoft when used in non-PKCS5 compliant mode
 
 Please fill in this template when reporting a bug, unless you know what you
 are doing.
 Description of Problem:
 
 
@@ -122,6 +122,61 @@
 The default iteration count is different between Mono (1) and MS
 (100). I wonder if this changed between 1.0/1.1 or 1.1/1.1sp ?!? as I
 (seem to) recall testing this. Anyway I'll add it to the test suite.
 
 Note: This is a separate issue from the reported bug (but will be
 fixed at the same time).
+
+------- Additional Comments From sebastien@ximian.com  2004-11-03 11:36 -------
+I fixed the exception part (CVS HEAD only until fix is complete).
+However I still don't get the same results as Microsoft. In fact I
+suspect that there's something "fishy" in MS implementation (which
+isn't exactly a PKCS#5 implementation if the number of requested bytes
+are bigger than what the hash algorithm produce).
+
+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 first 32 bytes are identical;
+* the last 8 bytes are also identical;
+
+So what happens is that the first hash (#0) produce 20 bytes (because
+it's SHA1 by default) which are identical (Mono vs MS). 
+
+The second hash (#1) produce 20 bytes, 12 bytes are returned for the
+GetBytes (32). Those 12 bytes are also identical. The 8 remaining
+bytes are kept for a future request (GetBytes).
+
+The second GetBytes (16) starts with the 8 previous bytes ***and does
+"something fishy" with them***. Then a third hash (#2) produce 20
+bytes and the first 8 bytes are returned (along with the 8 previous).
+The eight last bytes are also identical (Mono vs MS).
+
+Currently Mono returns the same data for GetBytes(48) than for
+GetBytes(32) + GetBytes(16) - which somehow seems logical ;-).
+
+*********************************************************************
+Note to reporter:
+
+If you want your code to be portable outside the .NET world (assuming
+I can fix this in Mono ;-) then you should stick to the PKCS#5 defined
+behaviour (i.e. request no more bytes than the hash function can
+produce) - or else only MS software will be able to reproduce your
+key/iv (a very bad situation if you need your data in a few years). 
+
+This is not only an interoperability issue - it's also a security
+issue. PKCS#5 doesn't provide more security than what the hash
+function can provide. So asking 32 bytes (256 bits) of SHA-1 doesn't
+give more than 160 bits of security (assuming a brute force attack).
+
+If you need 48 bytes then you should either SHA-384 (48 bytes max) or
+SHA-512 (64 bytes max). As an alternative you can generate a random IV
+and append it along the encrypted data (as the IV can be public).