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

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Wed, 3 Nov 2004 11:36:55 -0500 (EST)

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.


--- 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: ---
-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:
+Now if I request 32 bytes, then 16 bytes I get:
+* 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).