[Mono-bugs] [Bug 79499][Min] Changed - PasswordDeriveByte may derive *extra* data differently on ms.net and mono

[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 sebastien at ximian.com.

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

--- shadow/79499	2006-09-25 22:39:23.000000000 -0400
+++ shadow/79499.tmp.11766	2006-09-25 23:39:16.000000000 -0400
@@ -3,21 +3,21 @@
 Version: 1.1
 OS: other
 OS Details: Gentoo 32bit
 Status: NEW   
 Resolution: 
 Severity: Unknown
-Priority: Major
+Priority: Minor
 Component: CORLIB
 AssignedTo: sebastien at ximian.com                            
 ReportedBy: carlos at applianz.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
 Cc: 
-Summary: RijndaelCipher works differently on windows ms.net and linux mono
+Summary: PasswordDeriveByte may derive *extra* data differently on ms.net and mono
 
 I am trying to encrypt a value on mono 1.1.10.1 using RijndaelCipher but
 windows XP with ms.net can not decrypt it. I tried encrypting the same data
 with both ms.net and mono and the returned values were different. 
 
 Below are the methods used for encrypting and decrypting:
@@ -65,6 +65,47 @@
             byte[] plainbytes = new byte[cryptbytes.Length];
             int bytecount = cs.Read( plainbytes, 0, plainbytes.Length );
             ms.Close();
             cs.Close();
             return Encoding.Unicode.GetString( plainbytes, 0, bytecount );
         }
+
+------- Additional Comments From sebastien at ximian.com  2006-09-25 23:39 -------
+This is not related to Rijndael or any cipher (and I updated the bug
+summary to reflect this). Your problem occurs before using the
+algorithm, as you're supplying different key/iv on Mono than on
+Windows (try adding Console.WriteLine with the key/iv) and that just
+can't interop.
+
+Also the supplied (sample?) code has several problems:
+
+First it's it's overly complex and that's generally a bad sign.
+
+Second, it's mixing encodings with crypto, which is (at best)
+*dangerous*. Crypto needs unchanging values but, sadly, encoding may
+vary between computers / os / versions... (e.g. different
+implementations, buggy implementation, standard revisions...).
+
+Third, it's not using the PasswordDeriveByte as it should be:
+(a) the password and the salt are derived from the same "salt"
+(believe me there are good reasons why it's asking for two parameters
+and not a single one);
+(b) you are getting too much data from it. You shouldn't get more than
+20 bytes out of PasswordDeriveByte. Why ? because it use SHA1
+internally (limited to 20 bytes). Even if MS allows to get more, the
+specification does not (again for good reasons). You getting 32 bytes
+for the key itself (i.e. the last 12 are near worthless).
+
+Note: if you're targetting 2.0 please use the newer Rfc2898DeriveBytes
+class (and consider PasswordDeriveBytes good for compatibility only).
+
+
+I would normally close this as NOTABUG but it looks like you have find
+a bug. It seems that Mono's PasswordDeriveBytes doesn't derive the
+same bytes between the 32 and 40 positions (the first half of the IV).
+
+Note that deriving more than 20 bytes is actually not part of the
+PKCS#5 standard (actually the standard says to *abort* in such case)
+and this "extension" is undocumented by Microsoft (making it a very
+bad feature to use for interop). It seems my attempt to match the
+derived data isn't 100% correct so I'll get a look at it (but I
+downgraded the priority).