BTW: while this was reported for credit card number decryption, it would happen for any entity field with encrypt set to true.
I was working on this over the weekend and committed a couple of patches that failed to make a difference (testing against a real production database).
This time I actually reverted the code to the old state and created a fresh database with a credit card number in it, and then updated to the latest code to see what was broken and where.
Tracing it down the problem was not with the hex encoding or decoding of the encrypted credit card value (as I had thought), but instead was a problem the DES encryption key being used to decrypt being different than the one used to encrypt, and the reason is the ID for each key was SHA hashed and the hashing is what changed. So, now it looks up the DES keys for both the old and the new hash techniques and tries to decrypt with both of them.
This turned out to be the only possible fix because for systems updated recently they would have 2 DES keys for each entity, one with identified by the entity name with the old hash, and one with the new hash.
So, now updating with the patch from SVN rev 670731 things should work again.
If anyone runs into more trouble with this, please let me know! -David
