3
$\begingroup$

(I had posted this question on stackoverflow and been asked to move it to crypto.)

I have a question related to encrypting data in the database, at the application level.

The application will encrypt the data (e.g. using AES) when persisting it to the database and decrypt the data once they have been retrieved from the database.

Is there any good technic to renew the encryption key?

If for example a company has a policy to renew the encryption key every two years we would end up in a position where we have to decrypt the overall database with the old key, and reencrypt it with the new one every two years.

Is there any technic to avoid such an issue?

I had the following answers: https://stackoverflow.com/questions/37172931/application-level-encryption-and-key-renewal

I mentionned AES because it is an industry standard. Would Paillier be fit for the industry?

Improve this question
$\endgroup$
2
  • $\begingroup$ What about this: For data access you use one set of keys which decrypt the keys actually used in the database. If I'm reading this correctly you must rotate the database-internal keys every two years. Thus you partition your database into chunks with the same key and renew 1 out of 700 entries every day. This way you've renewed the keys for all entries every two years. As you have a key-seperation your application won't notice the key rotation (except that the actual access keys change from time to time). $\endgroup$
    – SEJPM
    May 14, 2016 at 14:07
  • $\begingroup$ That is a smart idea :) $\endgroup$
    – Gilles
    May 14, 2016 at 14:33

1 Answer 1

Reset to default
2
$\begingroup$

DEK (data encryption key): The key that encrypts the actual content. The DEK gets changed less often than the KEK (see below).

KEK (key encryption key): The key that encrypts the DEK. The KEK gets changed ("rotated") at regular intervals according to best practices and company security policies.

As the volume of content grows, the more arduous it will be to rotate the DEK. You still might actually rotate a DEK from time to time, but doing so would mean re-encrypting all of your content with a new key.

It is much easier to simply use a new key to re-encrypt the DEK, rather than re-encrypting the content that was encrypted by the DEK, since encryption keys are tiny compared to the content that they encrypt.

You should rotate the KEK as you go, over time, whenever its expiration date passes, or incidentally, such as in the event of a breach or a suspected breach.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks a lot. Please correct me if I am wrong. In this case it means that I have to keep track of the historical DEKs to be able to decrypt the data. E.g. I will always encrypt with the latest DEK, but need to access the correct DEK to decrypt data (the DEK that was used to encrypt the data at the time the data was encrypted). Is that correct? $\endgroup$
    – Gilles
    May 15, 2016 at 12:17
  • $\begingroup$ You can have a table which exists solely to store encrypted DEKs alongside other fields which point back to the table, row, and field of the content that was encrypted by the DEK. Once you have stored your encrypted DEK like this, you would discard the actual DEK from memory. The DEK can now be determined only by decryption by its corresponding KEK. $\endgroup$
    – vrtjason
    May 16, 2016 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.