Using multiple cryptographic keys for encryption? 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.


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. 
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.
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.