3
$\begingroup$

I am setting up an encryption methodology for items in a database. To decrease the likelihood of data being compromised due to the keys being compromised I would like to use an application level key (stored outside the database on a different server), a database level key (stored in a table away from data), and a data level key (stored inline with the data).

All of the keys are all AES256, encrypted at rest, and generated in a cryptographically sound way; they require a key management service to generate them and decrypt them. I have two methodologies in mind.

  1. Gather and decrypt the keys at the same time, and immediately hash them together with some data context that describes the data to make a new single 256bit encryption key specific to that data. Then immediately delete them from memory; the hash remains in memory long enough to perform a single encryption/decryption, but is eventually deleted and never stored to disk. If it is compromised in memory, only the data it matches could be compromised.

  2. Keep all the keys in memory long enough to successively encrypt/decrypt with each key. This runs the higher risk of the decrypted keys being individually compromised since they are in memory longer, but it seems like since entropy is added on each encryption step, it’s probably a stronger encryption in the end. Certainly the number of stored bytes increases (partially because of storing initialization vectors).

Is one method more secure/standard? Is there a more standard way of achieving what I’m trying to do? References would be great.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

A more standard way is not to make any of this yourself. Use a proper database like Oracle 11g. It's all built in. And you can even use it for free in some circumstances.

You think that it's simple just to AES some records in, but there's a great deal more for a production system. Oracle have spent millions developing all this functionality and vastly more like key and privileged user management and backup/restore whilst addressing all the performance issues. How would you handle encrypted joins for example? You won't do better building something yourself.

Have a look at their transparent data encryption FAQ.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks for the suggestion. I’m certain I wouldn’t do better myself, but changing the database architecture (mysql) isn’t an option unfortunately. I believe I’m following best practices in the actual encryption/decryption of values. Performance penalties are what they are, and are of secondary concern. As far as joins are concerned, it’s part of our design not to allow encrypted joins (sensitive data is stored only once); joins are performed on nonsensitive, unencrypted tokens. It’s really a question of key management: what key/keys to use and how many enecryption passes to make. $\endgroup$
    – juacala
    Mar 17, 2018 at 14:45

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.