Using ColdFusion to create an Encryption / Decryption Key from Plain Text
I have been doing work with Encrypting something in ColdFusion and decrypting it in ColdFusion. I've wrote about these experiments before. I've been trying to figure out the best way to create a key.
In ColdFusion I could easily use the GenerateSecretKey function. However, if I do that, how would I pass that key to Flex? It would have to be hard coded in some manner into the Flex Component that needed the encryption algorithm.
What I wanted was a way to generate the key on the fly. Flex and ColdFusion could both use the same algorithm for generating the key, and as long as I passed it appropriate parameters it would generate the same key, thus allowing Flex to decrypt something that was encrypted in ColdFusion.
So, how do you do it?
A 128 bit key is needed. This turns into 16 text characters. So, I started like this:
<cffunction name="generateEncryptionKey" access="private" output="true" returntype="string">
<cfset var HexKey = "">
<cfset var Filler = "abcdefghijklmnop">
<cfset var keyInText = "">
This is a function definition. It defines 3 local variables, one is HexKey. This will be the key, in hex, that we return from the function. The next variable is filler. If our algorithm generates a key that is less than 16 characters, we'll want to pad it. The final local variable is the keyInText. This will be the text representation of the key.
Write some algorithm to generate a key here.
It wouldn't be appropriate for me to share the algorithm we are using for key generation. But, the next chunk of code would generate it based on some factors that can be determined on the server in CF and on the Flex client.
<cfif len(keyInText) LT 16>
<cfset keyInText = keyInText & Filler>
</cfif>
<cfset keyInText = left(keyInText,16)>
IF the key is less than 16 characters, it adds in the filler. Then it truncates the key, removing all but the first 16 characters. We now have a 16 character key, no matter what the results of our "dynamically generate a key" algorithm.
<cfset HexKey = stringToHex(keyInText)>
Next we turn the text key into Hex. I'm using the stringToHex function from cflib to do this.
<cfreturn ToBase64(BinaryDecode(HexKey, "Hex"))>
</cffunction>
I'm undecided on the wisdom in an approach like this. When sharing between systems in the past, I have used a hard-coded key that was pre-generated for the purposes of sharing. Is a "semi-random" key generator more or less secure than a hard coded key that was randomly generated?
Discuss amongst yourselves!
This is a complex area, of course, I just dable.
But if you're trying to avoid users that have access to the Flex SWF from being able to fairly easily get the single decryption key and be able to decrypt everything coming down the wire, then the "semi-random" as you put it might be better as all new content either for the session for for each request would use a new decryption key and make breaking into the Flex SWF is a bit less valuable.
But with both types, the decrypted content will be available to the Flex app at some point and therefore accessible should someone desire the info enough, so the encryption won't help out all that much for determined nefarious characters.
So I think it comes down to: How hard do you want to make it on yourself and your applications. While encryption may not be an expensive operation for relatively small content, or relatively few transmissions, you should think about what the impact will be of encrypted with large content and/or large numbers of sessions/requests (assuming that your application is likely to have such an issue, it may not) and is that a good price to pay for the encryption.
A nice wishy-washy answer if I do say so myself. :-)
We're having similar discussions at my company about encryption/protection and it seems to get going 'round in circles, so I'm looking forward to hearing what others have to say on the topic.
I've been thinking about this a lot. We're no dealing with passing back and forth between client and server. In our use case, we believe that the data will be decrypted at some future point with no access to the original server / algorithm.
For various reasons, I'm not sure it would be appropriate for me to go into more details, though.
I do appreciate both of your comments; It has given me food for thought.