-----------
Problem #1:
-----------
Database entries are either recorded in plaintext or all encrypted using a single key. When recorded in plaintext, if access to the database is ever compromised, all of the data in the database is also compromised. Even when encrypted, there is still a single point of failure: if the filesystem access to the server is compromised, so is the key used to encrypt the database entries and the database itself.

This is especially problematic when the data stored in the database is sensitive user data: credit card and other personal information is not uncommon.

-----------
Solution:
-----------
At user registration time, a private key is generated and encrypted with a passphrase derived from the user's password and other information. The password, as normal, is hashed with a cryptographically secure algorithm and stored in the database for later authentication. The passphrase for the private key (or the private key itself) is stored in-session and these are used to encrypt the user data which will be stored in the database.

This solution increases the level of security breach required for gaining access to user data significantly, and even in the worst case scenario, it is unlikely that all user data can ever be compromised (all of this provided that session data is handled securely).

-----------
-----------

-----------
Problem #2:
-----------
However, another problem is presented when this data needs to be shared with a user other than the owner. For example, the owner has personal data containing his name, email address, and phone number; he wishes to allow another user, the recipient, to access his name, but NOT the other two values; to a different recipient he wishes to grant access to all three.

Because his private key is only available within his own session, and encrypted with his password, which is only ever available at login time, these users are not able to decrypt the values in question. This necessitates the usage of asymmetric encryption.

With traditional asymmetric encryption algorithms, however, it is not possible to encrypt three messages with a single private key and still segment which messages can be decrypted with the public key, which seems to make encrypting each of the messages with a different private key and simply handing out the public keys which are relevant to the messages you wish to share the only way to go. For a number of reasons (not least among which is data inflation), this is not desirable.

-----------
Possible Solution
-----------
I just thought of this, so I haven't had time to really think about the implications. Consider that our messages 'name', 'email', and 'phone' are encrypted securely in our database using the method described above, with our securely encrypted private key. When sharing keys to this data, the public portion of our private key is made generally available and each key is additionally encrypted with the private key-encrypted field name (e.g. 'name'). When granting access to these fields, we encrypt the encrypted field names we wish to share with the recipient's public key and give them that data; they are then able to know which fields they are able to know, as well as being able to decrypt them

LIMITATIONS include not being able to revoke access to resources once you have shared them without re-creating the public key and reissuing data keys as necessary.