I am encrypting a secret in a db field.

I am encrypting using AES with a 256-bit key and a random IV per encryption.

They AES key is hard coded in the code. Each IV is stored in clear in another field in the row containing the cryptogram.

How can I improve this encryption? I believe I need to encrypt the AES key but I am unsure of the best scheme. Please advise.

The secret is encrypted and decrypted by the same component. I need to persist this (cryptogram of the) secret. I am using C#.

  • @Thomas Pornin An initial attack model would be attacker obtains a copy of the db containing the cryptograms. If he also got the code or reversed the code he can get the aes key and decrypt the secrets. I agree that you could keep encrypting keys n times which adds very little to no security. The data is not decrypted on the user's machine. I think I will opt for requiring a human entered password at application launch time that loads the AES key into memory. Any suggestions on this implementation? Salt & hash the password but where do I load or generate the aes key from if the hash matches?
    – Sam Leach
    Oct 28, 2013 at 23:10

1 Answer 1


The AES key is hard coded in the code.

This is the problem. But, no, encrypting the key with another key (which would be hard coded in the code) does not substantially improve matters.

What you must do is the following: write down the attack model. You are doing encryption for a reason: you believe that some evil individual will try to do... what exactly ? That's the point of the attack model: to define what the supposed attacker can do, and what he will want to achieve. Only with a clearly defined attack model can you begin to think about what security algorithms and protocols will help you.

For instance, encryption is a good tool for confidentiality: that's when the attacker wants to read some data, but you don't want him to succeed. Encryption does not solve confidentiality; it just concentrates the problem: with encryption, the problem of keeping the data confidential becomes the problem of keeping the key confidential. Since the key is shorter, this may (or may not) make the problem easier to deal with. An important point is to decide who should be able to access the data.

To make the story short: if the data is supposed to be decrypted on the attacker's machine (e.g. the attacker is the user, and you want to prevent him from accessing the raw data as part of some sort of licensing or DRM scheme), then, to put it bluntly, you lose. You cannot reliably and consistently prevent someone from accessing data which flows on his own hardware. That's because reverse engineering works well. If you pile up encryption layers (key is encrypted with another key which is encrypted with another key, and so on, up to an initial key which is hard coded), you just increase both the development time and the reverse engineering time; chances are that it will cost more time for you than for the attacker.

You must log in to answer this question.

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