Be Excellent To Each Other

I have a web application with an associated mySQL database.

They're both on the same server, and this cannot be changed as the client basically won't spring for it.

The application needs to store encrypted data in the mySQL database. I already have this implemented* but currently while I'm testing it I'm just using a single encryption key and a single authentication key.

This seems stupid, for obvious reasons, so what I'd quite like to do is have a unique key for each entry in the database.

The obvious problem then becomes that of key storage - if I want to decrypt the data for display (which I do) I need to store the key somewhere that can be related to the entry. Storing the key with the entry seems pointless though.

Is there a decent way of handling this? What about if I have a key which isn't stored anywhere on the server, that is used to encrypt the entry's key? Then the authenticated user can input this key and have the data decrypt? If I did the decryption in JavaScript (assuming it's possible) then this key would never need to be transmitted across a network so should be safe, right?

Or is there another approach that I'm missing?

AES-256-CTR using a hmac, if that matters

Make the key their password? I assume you've got some bad-ass one-way encryption on the password field, so check the password against that field, and if it's correct you can use it to decrypt the data. That does mean the key goes across the network to check it's correct (I guess that's not entirely necessary, though).

You'd have to have them enter their password every time they wanted to update the field too, but there's no way around that without storing it.

It needs to be accessible by multiple users, so that's a no-go.

//edit: They don't need to edit the encrypted data though, so that's a plus. Once it's encrypted it can stay as such in the database.

Unless you have them write the key down when they encrypt the data, I think you're stuck. It's got to be stored somewhere for this to work, I think.