[Mono-bugs] [Bug 74645][Wis] New - Windows does not decrypt the first block correctly when decrypting some data that was encrypted using mono

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Mon, 18 Apr 2005 01:00:08 -0400 (EDT)

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 eric@extremeboredom.net.


--- shadow/74645	2005-04-18 01:00:08.000000000 -0400
+++ shadow/74645.tmp.8067	2005-04-18 01:00:08.000000000 -0400
@@ -0,0 +1,157 @@
+Bug#: 74645
+Product: Mono: Class Libraries
+Version: 1.0
+OS Details: Linux and Windows XP
+Status: NEW   
+Priority: Wishlist
+Component: System.Security
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: eric@extremeboredom.net               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+Summary: Windows does not decrypt the first block correctly when decrypting some data that was encrypted using mono
+Description of Problem:
+Windows does not decrypt the first block correctly when decrypting some
+data that was encrypted using mono.
+spouliot! here's the IRC log as you requested! Please email me or catch me
+on IRC again if there is anything I can help you with!
+Thanks a lot!
+<FireRabbit> hey, could you please let me know when you get back? 
+<spouliot> here I am!
+<FireRabbit> hey, so you did a lot of the System.Security stuff right?
+<spouliot> yep
+<FireRabbit> awesome .. so I am having a problem where when I encrypt
+specific data on mono and try to decrypt it using the .net framework the
+first 10 or so bytes are wrong
+<spouliot> you have some sample code ?
+<FireRabbit> i havent been able to create a testcase its fairly embeded
+into my application ... do you want to test that? its very easy to reproduce..
+<spouliot> open a bugzilla issue with a link to the source code and
+instructions to reproduce
+<spouliot> I'll look at it tomorrow
+<FireRabbit> hm okay, we will try to put together a good test tonight.
+<FireRabbit> its a real pain to test this because it requires a windows and
+linux box basically 
+<FireRabbit> it also doesn't happen with everything that I encrypt .. but
+does happen regardless of if I use 3des or aes.
+<spouliot> I got them - not that I like the requirements to reproduce a bug ;-)
+<spouliot> what mode and padding are you using ?
+<FireRabbit> i tried a bunch of different ones and had the same problem ...
+i think it's using the default one now.
+<spouliot> are you using CryptoStream or not ?
+<FireRabbit> I could have sworn that in 1.1.4 this was fixed (it doesnt
+work in anything newer) but i havent gone back to confirm this.
+<FireRabbit> yeah, CryptoStream.
+<spouliot> it may be a bug in CryptoStream - or in the way you're using it.
+<spouliot> the first block is probably mis-decrypted due to the state of
+the stream (e.g. bug or a missing flush)
+<FireRabbit> hmm.
+<FireRabbit> do you see anything i am doing obviously wrong in those
+Encrypt/Decrypt methods?
+<FireRabbit> (this does work mono<->mono)
+<spouliot> where is the ICryptoTransform created ?
+<FireRabbit> in this file:
+<FireRabbit>                                         deTransform =
+cryptoProvider.CreateDecryptor(keyBytes, ivBytes);
+<FireRabbit>                                         enTransform =
+cryptoProvider.CreateEncryptor(keyBytes, ivBytes);
+<spouliot> nothing bad at first look - but you're creating a lot of objects
+for the job (as I guess your data is small as it looks like a password)
+<FireRabbit> no, its more than a password .. all the socket traffic gets
+<spouliot> so you're creating a CryptoStream/MemoryStream for each
+encrypt/decrypt operation ? (anyway it's offtopic ;-)
+<FireRabbit> yeah well once it _works_ i'll fix that.. its been on my list
+<spouliot> well I don't want to hide the bug before finding it - but it
+would probably _work_ (and faster) if you use the ICryptoTransform methods
+<FireRabbit> TransformBlock?
+<spouliot> the CryptoStream is nice if you're already working with stream
+(or plan to) but if you're dealing with byte arrays then the
+Transform[Block|FinalBlock] are easier (and requires much less overhead)
+<FireRabbit> shit I never even noticed those methods before :P
+<FireRabbit> well initially i was hoping to be able to create the
+cryptostream ontop of a networkstream but THAT wasnt working either .. so
+one thing at a time yes
+<spouliot> they are not easy to see as the ICryptoTransform classes are
+(mostly) not public
+<spouliot> have you verified that the key and IV are identical on both side
+? (i.e. that it isn't a key exchange problem ?)
+<FireRabbit> i think so but i will double check again.
+<spouliot> I'll try to duplicate the problem with your code. The only
+missing info I need is the typical size of the data you encrypt/decrypt.
+<FireRabbit> i can tell you exactly in one sec .. ill make it write the
+size as it recieves..
+<FireRabbit> okay this is 772 bytes..
+<spouliot> k
+<FireRabbit> if windows would stop crashing i could verify the key/iv...
+<FireRabbit> yep, looks good.
+<spouliot> k, I'm on the case
+<FireRabbit> would you still like me to file a bug?
+<spouliot> yes please. it helps for history
+<spouliot> you can copy/paste our IRC log to make it short, I'll update it
+<FireRabbit> okay one sec
+<spouliot> does the same code works without encryption ?
+<FireRabbit> oh yeah, if i comment out my encryption stuff it works.
+<FireRabbit> or if i overwrite the first block with the correct data manually
+<spouliot> it cannot be a mis-use of the CryptoStream because it's only
+used locally (re-using it could lead to problems if care isn't taken)
+<FireRabbit> right.
+<spouliot> I made a sample with your code (and a similar ICryptoTransform
+code) and I get the same results with both implementations on both Linux and XP
+<FireRabbit> same results meaning same error as me or it works properly?
+<spouliot> works properly
+<FireRabbit> damn ! i dont know what it is about what i am encrypting ...
+<FireRabbit> so your encrypting on linux and decrypting on xp?
+<spouliot> yes I encrypt/decrypt on both and show the encrypted/decrypted
+<spouliot> ok, I recall a issue someone had a few months ago...
+<FireRabbit> the problem is only when you encrypt on one platform and
+decrypt those bytes on another
+<spouliot> that's what I do (on a command line)
+<FireRabbit> oh ok
+<spouliot> what kind of data are you transfering ?
+<FireRabbit> binary serialized object
+<spouliot> did you try mono on XP ? or only the MS runtime ?
+<FireRabbit> only the MS runtime since thats what i am targeting on windows
+<spouliot> I'm gonna attach my sample code to the bug report so you can try
+it too - what's it's number ?
+<FireRabbit> havent filed yet. one sec.
+<FireRabbit> i had tried writing a simple test case too and it worked as
+well...so its gotta be some little thing throwing it off
+<spouliot> very possibly - but I don't see what could affect the
+CryptoStream since it's only used locally
+<spouliot> Are the Linux/Windows software identical in functionalities ? if
+so does the problem happens on both side ?
+<spouliot> I assuming that W->W and L->L works and that W->L and L->W doesn't
+<FireRabbit> its the same dll on both platforms
+<FireRabbit> let me test W<->W real quick.
+<spouliot> I must go. Did you fill the bug ?
+<FireRabbit> about to do that (sorry, people are very distracting here) ..
+what's your email? I'll send you the bug#?
+<spouliot> just assign it to me - I'll receive the bug#
+<spouliot> sebastien@ximian.com
+<FireRabbit> okay
+<spouliot> what's yours ? I'll send you the sample code to try
+<FireRabbit> eric@extremeboredom.net
+<FireRabbit> should I include how to use Meshwork to test this in the bug
+report or shoudl i try to write a test case ... or what? meshwork would
+take a few minutes to set up ...
+<spouliot> keep it simple. Just copy/paste the IRC log in it so I don't
+loose history and details if I cannot work on this tomorrow morning
+<FireRabbit> okay
+<spouliot> cya
+<FireRabbit> thanks a lot !