What if you wanted to encrypt your data using ColdFusion and then decrypt it in another language or on another platform not using ColdFusion?
Or perhaps you need to do the reverse and encrypted something in another language and decrypted it with ColdFusion.
In theory it would be great to use the embedded encryption that comes with ColdFusion to handle both of the previously mentioned scenarios.
However, unless the Encryption solution has been verified to be implemented consistent with the National Institute of Standards and Technology (NIST) standard you might get radically different encryption and decryption results that are simply not consistent from one language to another or one platform to another.
The example we most frequently run into is merchants wanting to encrypt payment card transaction data within their shopping cart, as required by PCI-DSS and privacy laws that exist in many states, and then decrypt that same data on a different platform. If the encryption solutions they use in these different environments are not implemented exactly the same and consistent with the NIST standard, then it may be impossible for them to exchange the encrypted data between platforms and/or languages. Specifically, since ColdFusion's internal encryption implementation produces results that are not consistent with the NIST standard, its usefulness is limited to ColdFusion.
When considering whether to use ColdFusion's internal encryption implementation, a .Net, or other crypto offerings including CFXWorks' CryptoXpress CF product the following issues are important to consider:
- Does the offering support strong encryption as defined by the National Institute of Standards and Technology (NIST)? A number of government standards require the use of "strong encryption". AES is the standard within the department of defense and is required for use by organizations doing business with the DOD.
- Does the offering support TripleDES (DES3). TripleDES is still used a great deal in some industries including the banking and securities industry.
- Has the vendor validated the results of their implementation using the test vectors published by the NIST? Unless they have validated their results using these test vectors then the results they achieve encrypting data are not likely to be correct.
- Is AES encryption supported in both CBC and ECB mode? If both modes are not supported it may be impossible to exchange your encrypted data across platforms and solution bases.
- Is PKCS5Padding supported in CBC mode? PKCS5Padding is the most popular padding technique. If your encryption solution does not support PKCS5Padding in CBC mode it will be nearly impossible to exchange data with other users.
- Has the vendors implementation of encryption been validated across different platforms that use different encoding schemes. For example, some platforms code data using ASCII encoding. Other platforms use EBCDIC encoding. How would one ever use ColdFusion's encryption solution to encrypt data on an Intel platform and then decrypt it on an IBM iSeries or mainframe?
Encryption can be a very confusing topic. If you have any question please don't hesitate to contact us.