(I wrote this back in October of last year, never bothered to post it. I probably had a reason for that, but it’s long forgotten by now, so I might as well post what I had.)
So I wasted a great deal of time trying to get my SHA-256 hashes from a .NET application to match up in a PHP application. It seemed really like it should be straightforward: make sure your string has a known character encoding, SHA-256 digest it, and then base64 encode it. How hard could it be?
Well, after a day of ripping my hair out, I concluded it’s harder than it seems. Here’s what the problem is: the application I’m trying to match encodes the strings as UTF-16 before hashing them. Unbeknownst to me, the double-byte strings are big-endian in one case, and little-endian in the other, even though they’re on the same Intel box. Took longer than it should have to track that down.
Oh, but is that the end of it? No, no, no. No, it’s not.
I also had to decrypt some strings. It was encrypted using the ManagedRijndael class, and I had the key and iv string. Those strings also got encoded into wrong-endian UTF-16, which was easily fixed (once I knew what was going on). But I was still getting gibberish. Well, to make a very long story short, the ManagedRijndael class in .NET and the mcrypt_generic function using Rijndael256 algorithm in cipher-block chaining mode in PHP aren’t exactly compatible. The mighty Google finally pointed me to the solution, which is using the Rijndael128 algorithm. The ManagedRijndael class creates actual AES-256, which mcrypt_generic is using Rijndael, which differ in the length of the initialization vector. Switching to the Rijndael128 but still passing the 32-bit key is equivalent to the AES-256.
What’s all this mean, then? This is all stuff that’s probably pretty obvious to anyone who knows anything. I, however, found this bewildering and confuzzling.