[pmontra]

I won't answer directly, please don't be upset.

Did you already perform a threat analysis and a risk assessment?

Who are you defending against? Which are the attack or data breach scenarioes?

Put them in a impact / likelihood matrix and defend against the most serious combinations.

Do you still need to encrypt live data in the db?

If positive, an approach I used in the past was to never perform any operation in the server. Users were storing their private key in the browser (local storage) and decrypt data on the fly in JavaScript (you have to trust the browser js engine bugs.) The server could generate and store data for them using the public keys but nothing more.

If you need server side aggregations you can store in cleartext site parts of the encrypted information. Example: city names give you users per cities, regions states, countries.

Be careful about reidentification using extra information attackers could know about your system and users.

[flashu]

Thank You for the reply!

I think I've made some mind shortcuts and now I see them after reading Your questions.

The thing is that I have to access data stored in the encrypted database/storage because it must be accessible by an application process without any interaction from the user. Data will be decrypted on-demand by background worker using the key which I have to store somewhere and which must be secured somehow and available only for that process.

So far, my idea is flying over solutions like ionCube / Zend Encoder to encrypt/encode/secure the source code of the application or only parts of it to prevent exposing the logic responsible for getting out the data among with keys themselves.

Can I call it: poor-man encryption? :-)