I have a situation where my web application is going to be deployed on multiple web servers, and I'll be wanting to store some securely encrypted data on the DB servers (each web server has a DB server paired with it).

Now, what I was thinking of doing was implementing Encrypt and Decrypt library functions that utilize the AesManaged class. These would use an AES key that would be different for each server (we would generate a new one for each server on deployment) - that way, each server would be using a different key. We would then use SectionInformation.ProtectSection() to encrypt them in Web.config, so they were secure.

However, I've come accross the ProtectedData class. This hooks into the Windows DPAPI functionality and allows symmetric encryption and decryption. Now I'm wondering, is there any point in my using AesManaged with my own generated keys at all, or should I just encrypt and decrypt data using ProtectedData? What are the pros and cons of each?

  • You just want to securely store the Web.config file on the disk and nothing more?
    – M'vy
    Commented Mar 25, 2015 at 8:18
  • No, I'll be wanting to store some encrypted data in a DB on each server. I've updated the question.
    – Jez
    Commented Mar 25, 2015 at 8:23
  • and your database doesn't support data encryption, or are you trying to store the data post encryption?
    – Jim B
    Commented May 6, 2015 at 15:20
  • 1
    @JimB This is doing the encryption at the domain services layer, because we're using a domain-driven design. We can't rely on a particular database, so no, we can't rely on the database supporting data encryption.
    – Jez
    Commented May 6, 2015 at 15:29
  • Ahh OK, so you are kinda stuck in that case. You might want to ask on stackoverflow, they still have folks using that model.
    – Jim B
    Commented May 6, 2015 at 15:32

2 Answers 2


This is probably a little late but just as a recommendation for other people who stumble on this. For this type of problem I would always use ProtectedData over rolling your own implementation with AesManaged for two reasons. First, you don't need to deal with managing cryptographic keys with ProtectedData which is a hassle to do correctly. Second, there's a handful of security considerations that a developer needs to understand before hand-rolling their own crypto and even then there's a chance the developer could make a mistake and render the crypto useless. Why take the chance and risk a headache when a perfectly acceptable, already vetted, solution is already available?


As Justin referred, using your own keys and then manage them is a no go. That is why you have OS or language mechanisms to do this for you. In java you have local key stores protected by passwords. The cons of relying on the OS to protect your keys is that in case the underlying OS is corrupted in some way, you will probably lose those keys forever. Why won't you use RSACryptoServiceProvider with the CspParameters to create a store with your own keys?

Read: https://msdn.microsoft.com/en-us/library/tswxhw92.aspx


I think this might help you. In this way you are not bounded to key choices of the OS and can keep your own keys safe away while protecting them locally on stores.

Stay safe ;)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .