If I am to store different types of sensitive data, let's say: field1 in Table A and field2 in Table B and the data is unrelated, should I use a different key for each field?

Add information 1: The encryption/decryption is going to take place in the application code and the database will only store the encrypted data.

Add information 2: Right now, I'm planning to use AES-256-CBC and the database is MongoDB.

  • There are many encryption strategies, some builtin to DBs, others implemented by the app. Can you give us more context so that we can help you. Commented Apr 1, 2018 at 22:53
  • I second the request for more information. Specifically, what type of database are you using? Depending who you're trying to protect data from, it might also be worth considering whether the data may be transparently encrypted by the database (so the application never needs to know it was encrypted), or the application may handle decryption so the database server never has access to the date in the clear. This depends on the level of trust given to the database, whether you need to search on the encrypted data, and how paranoid you are.
    – nbering
    Commented Apr 2, 2018 at 1:21
  • 1
    Generally using the same key is fine, assuming you are OK with the fact that each field can be decrypted with the same key (should be obvious). You must use unique IVs however, but if the encryption implementation for your database is made correctly, it will handle that for you.
    – forest
    Commented Apr 2, 2018 at 9:16

2 Answers 2


Based on the information provided in the update, I would suggest to use the same key for each field. Different keys would be an overkill as you might want to encrypt other fields as well and also it would be cumbersome to map the fields with different keys.

Following points can be considered with this approach :

  • The encryption key is not stored at the same db where encrypted data is being stored. (consider to store in configuration file)
  • The encryption key should be sufficiently long to prevent any brute-force attack on the key itself.
  • Based on the frequency of usage and sensitivity, decide whether to use Symmetric or Asymmetric. (refs : comments)

Edit 1 :

  • If using the config file to store encryption key, make sure to not commit the key accidentally. Instead, commit a dummy key and replace it during deployment.
  • -1 for the last point. I can't see any possible reason why symmetric vs asymmetric should be decided on based on "frequency of usage and sensitivity". They have completely different purposes (key exchange vs confidentiality, for example).
    – forest
    Commented Apr 2, 2018 at 9:12
  • @forest, It's because, symmetric is faster as compared to asymmetric. [en.wikipedia.org/wiki/… Also, please consider the overall answer for the downvote. Commented Apr 2, 2018 at 9:14
  • But why would you ever want to use asymmetric crypto for encrypting local files in a database? It's only useful for doing things like encrypting data over a network where the two parties do not yet have a shared secret. Can you elaborate in your answer why you would ever want to use asymmetric cryptography for locally encrypting fields in a database?
    – forest
    Commented Apr 2, 2018 at 9:15
  • 1
    Got the point. Thanks for making it clear. Shall update the answer. Commented Apr 2, 2018 at 9:19
  • 1
    A configuration file with appropriately set file permissions is a better choice. If I recall correctly, environmental variables aren't supposed to be used for confidential information. Commented Apr 2, 2018 at 14:07

It depends.

In general, the primary reason for using different keys is: you might want to supply different parts of the data to different subsystems. If there are some columns processed by a system A and some columns processed by a system B, you might want to use different keys for these groups of columns. (This consideration may also apply if one subsystem needs access to all the columns and another to only some.)

If, however, all processing happens within a single subsystem — that is to say, all the keys are distributed together and all parts of the data are always decrypted together —, managing separate keys will not be very beneficial at all in terms of confidentiality maintenance, and near-zero benefits will probably be outweighed by the costs of extra complexity.

So, this is the space axis. However, depending on your context, you might also need to consider the time axis, whereby the encryption keys may change over time, and/or data encrypted with different keys may need to be held in same columns. For example, a combination of a policy of regularly changing the encryption key and the costs of decrypting and re-encrypting a large set of data may necessitate protecting the accessibility aspect of data security by performing the re-encryption process by small steps, which means that during changeover, your system may encounter both data encrypted with the soon-to-expire old key and data encrypted with the recently-issued new one.

Coming back to what you asked — it is pretty unusual for a structured database to not be trusted to have access to data in it, so there are no established best practices for this kind of situations. It is more common to run the whole database on an encrypted data storage, usually in the form of a file system of some sort, or alternatively treat the database as a kind of block device, just serving opaque encrypted blobs whose whole meaning will then be determined in the part of the system which you trust enough to have the cryptographic keys. Analyse, for example, what kind of potential attacks you want to protect your system against. If you are concerned that an attacker may be able to read data out of your database, should you also be concerned that the attacker may be able to insert bogus data, possibly data he might not understand, into your database, or replace good data with bad data or garbage?

You must log in to answer this question.

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