How can I implement strong, reversible encryption that interfaces between ASP.NET 2.0, Coldfusion 5, and classic ASP?

Question

My organization decided to encrypt certain data in our database, and I was entrusted with the implementation of encryption. I need to be able to encrypt data, store the encrypted version in the VARCHAR field in our database, and then retrieve it and decrypt it back to its normal state.

The surface seems to be a simple task. There are many ways to implement encryption. The one I used earlier is based on the AES encryption code found in https://stackoverflow.com/a/167958/ .

What complicates this, I need to write code to encrypt / decrypt data in various applications that access our database, some of which are developed using different technologies. We have applications written in Coldfusion 5, in classic ASP and in ASP.NET 2.0. I need to be able to encrypt data and store it in a database using Coldfusion code, and then read and decrypt it back to its original form in ASP.NET. Or encrypt it in classic ASP and decrypt it in Coldfusion. Or any other combination of these platforms.

It turned out to be harder than I expected. Different classes / objects / functions / libraries that claim to use the same algorithms seem to generate different results, even if they give the same data and the same shared secret. We used to use CAPICOM to provide encryption compatibility between Coldfusion and classic ASP. But I ran into difficulties trying to get this to work in ASP.NET. I read this article on how to get CAPICOM to work in .NET , but the suggestions do not work for me. I can’t even create an interop class or import a reference to a COM object without getting an error. In addition, some of our production servers have operating systems that do not appear to be compatible with CAPICOM, so it could be a dead end anyway.

Does anyone have any suggestions on how I can implement encryption so that any of the three platforms can decrypt what others have encrypted while using a reasonably robust algorithm?

Edit 2011-12-29:

As noted in the comments below, I am currently hoping to find an ASP.NET solution compatible with some of our existing Coldfusion / ASP Classic that use CAPICOM. The reason for this is because our team does not want me to introduce a new encryption method in our code for our current purpose, unless I also review our old applications using encryption to use the same method for another purpose. He wants to use the same encryption method for both purposes. Since revising old applications to use the new encryption method means not just changing the code, but also tracking all the data encrypted by older applications, decrypting them and re-encrypting using the new method, I hesitate to go this route if I shouldn't. I hope I find a way to get ASP.NET to read existing encrypted data.

The encrypted data from our other Coldfusion and ASP Classic applications has been encoded using the CAPICOM COM object. As far as I can tell, the settings were universally AES encryption, the maximum key size (which, in my opinion, is 256-bit in AES).

The @Leigh query here provides a simplified example of how our existing CF applications use CAPICOM:

<cfscript> encryptObject = CreateObject("com","CAPICOM.EncryptedData"); encryptObject.Algorithm.Name = 4; // 4 is AES encryptObject.Algorithm.KeyLength = 0; // 0 is MAX, I believe 256-bit in the case of AES encryptObject.SetSecret(sharedSecret); encryptObject.Content = stringToEncrypt; encryptedData = localScope.encryptObject.Encrypt(); </cfscript> 

Answer 1

Since you have a common database platform between all systems, I would leave encryption / decryption there. Here's an article about column-specific encryption in SQL Server 2005:

http://msdn.microsoft.com/en-us/library/ms179331(v=sql.90).aspx

Answer 2

I just did a similar thing (encryption between classic ASP and ASP.NET, ignoring Coldfusion) and I came across CAPICOM several times too, but after a lot of talking and hacking (and searching) I found the COM AES / Rijndael library in which I ended up using Hyeongryeol.Security.Cryptography (for some reason, the download is called .wma - this is a zip file that you open manually with 7-Zip or whatever you use).

Encryping / decrypting in .NET uses the RijndaelManaged class (there is an example in the download).

Everything in general is very simple to work with. Just register the COM DLL (for classic ASP), and that should be fine. Here is an excerpt from our build.bat, which guarantees (hopes) that it is registered:

 echo Registering HyeongryeolStringEncrypter.dll copy Libraries\Hyeongryeol.Security.Cryptography\ASP\HyeongryeolStringEncrypter.dll %system32%\HyeongryeolStringEncrypter.dll regsvr32 /s %system32%\HyeongryeolStringEncrypter.dll 

Just make sure you use the same / IV key on each side.

Answer 3

After an extensive search on several sites, others offering SSO, but obviously with limitations, I came to the code below, which allowed me what I wanted.

• We have an existing CF site and are redesigning it using ASP.NET and a membership provider.
• We wanted to save passwords from an existing CF, but moved them to the aspnet_membership table and hashed them.
• We also wanted to be able to change the password from any system, since they will be executed simultaneously for no more than 3 months.
• This means that we wanted to be able to update the aspnet_membership table from CF and also verify the authenticity of this table.

In the code below, we can hash the password from CF and map it to the aspnet_membership table. If theBased64Hash matches the password in the table, the user can be authenticated. Now we can encrypt the password if the user wants to change the password on the CF side and will still be verified on the ASP.NET side.

Refresh (fixed concatenation problem)

 <cfscript> thePassword = "originalPassword"; base64Salt = "JZjdzUXREM0A7DPI3FV3iQ=="; // extract bytes of the salt and password saltBytes = binaryDecode(base64Salt, "base64"); passBytes = charsetDecode(thePassword, "UTF-16LE" ); // next combine the bytes. note, the returned arrays are immutable, // so we cannot use the standard CF tricks to merge them ArrayUtils = createObject("java", "org.apache.commons.lang.ArrayUtils"); dataBytes = ArrayUtils.addAll( saltBytes, passBytes ); // hash binary using java MessageDigest = createObject("java", "java.security.MessageDigest").getInstance("SHA-1"); MessageDigest.update(dataBytes); theBase64Hash = binaryEncode(MessageDigest.digest(), "base64"); WriteOutput("<br />theBase64Hash= "& theBase64Hash &"<br/>"); </cfscript> 

Answer 4

Encryption simply changes your data so that it is not readable by humans, and then modified it using a backward link to the original formula.

I will personally stick to AES, and you can get AES for these platforms.

Depending on how strong you are at this, you can simply write a simple function to do it yourself.

It can be as simple as adding a series of bits to information based on some key.