To understand what we are seeing in the configuration file, we first need to realize that the runtime turns to a configuration encryption provider for encryption and decryption work. The two providers shipping in .NET 2.0 are the DataProtectionConfigurationProvider and the RSAProtectedConfigurationProvider.

The purpose of an encryption provider is quiet simple - encrypt the contents of the specified section using a particular cryptographic engine and return the results as an XML node. Likewise, the provider must be able to decrypt the contents of a given XML node.

We can specify the provider we want to use in the string passed to the Encrypt method, as we have seen in the abovementioned code snippet. In our example we are using the DataProtectionConfigurationProvider.

The DataProtectionConfigurationProvider uses the Windows Data Protection API (DPAPI). This provides a machine-specific secret key for encryption and decryption work. Because the DataProtectionConfigurationProvider relies on a machine-specific key, we can only decrypt cipher text that was encrypted on the same machine; that means we can not use a configuration file encrypted in this way on any other computer.

If we need to move configuration files with encrypted sections from machine to machine, we need the RSAProtectedConfigurationProvider. We can copy this key between computers. The RSAProtectedConfigurationProvider, as the name would imply, uses RSA public key encryption. The RSA provider is used by default. However, if we do not want to write code, we can use the command line tool aspnet_regiis. Even though building our own custom provider is possible, the golden rule as far as encryption is concerned is, "Do not build your own encryption library, but use any reliable library that exists."