Saturday, December 15, 2007

TextBuffer.Encrypt() changes from version 3 to 4

In version 3.0 there is a basic method for encryption: TextBuffer.Encrypt(key). It is easy to use, but not very secure; so in version 4.0 it has been phased out. To make sure it is not used any more Microsoft eliminated it, but left in a decryption method to help customers migrate encrypted data. All this sounds good and reasonable, but I ran into a problem.

We had been using the TextBuffer.encrypt method to encrypt credit card numbers in v 3.0. When I tried to use the TextBuffer.decryptOld(key) in v 4, though, I found the DecryptOld method was not returning our data intact.

I've created a job to demonstrate the problem. If you run it in version 3, it works. If you run it in verion 4, the data gets corrupted.

Version 3 job =============

static void DecodeTest1(Args _args)
{
TextBuffer txt = new TextBuffer();
;
txt.setText("4444555566667777");
info(strfmt("Clear text: %1",txt.getText()));
txt.encrypt(123456);
info(strfmt("Encrypted: %1",txt.getText()));

txt.setText("ÔÑ2G¡.Ÿ¤®‹LAûH9þ");
info(strfmt("Encryped text: %1",txt.getText()));
txt.decrypt(123456);
info(strfmt("Decrypted: %1",txt.getText()));
}


===========
The output shows the text is encrypted to "ÔÑ2G¡.Ÿ¤®‹LAûH9þ" and then decrypted to plain text.

Now run just the decryption in version 4:
===========

static void DecodeTest1(Args _args)
{

TextBuffer txt = new TextBuffer();
;
txt.setText("ÔÑ2G¡.Ÿ¤®‹LAûH9þ");
info(strfmt("Encryped text: %1",txt.getText()));
txt.decryptold(123456);
info(strfmt("Decrypted: %1",txt.getText()));
}

The result is
Decrypted: 444455僮56鷄667777
instead of
Decrypted: 4444555566667777
(In case the unicode characters don't display, in the version 4 result the 7th and 10th digit are replaced by Asian characters.)

I did not see any fixes from Redmond and could not find anyone else reporting problems with the DecryptOld method.


We had to work around this issue by decrypting the data in version 3 to a temporary field. After the data conversion, the data was re-encrypted and the temporary field deleted.

Even though our conversion is done, I'd love to hear from anyone who ran into this same problem or knows about this issue.

No comments: