Question

I want my application (PHP, but that shouldn’t matter) to store some data in a shared repository (the APC user cache, but again irrelevant). To prevent users from reading eachother’s data I’d like to encrypt it per user.

I could have the user specify the key in his configuration file for the application, but I’d rather generate it automatically so the user doesn’t have to bother.

For this I would need a piece of data on the system that (almost) never changes and is only readable by the current user. I can then hash that, or something, to generate the key. Does something like that exist in a default user account on a Linux system?

Answer 1

Storing a key in ~/.yourApp will work, provided that you set the permissions of the key file to 0600 and the permissions of the ~/.yourApp directory to 0700.

Of course you are relying on people not being able / willing to use root access to access other users’ key files. If that is a concern you are going to need to use some kind of keystore where access is controlled by a master passphrase.

EDIT : in answer to the OP’s followup questions below:

Even then the master passphrase must be stored on the system, or users will have to enter it manually for every request (I assume even storing it in memory is unsafe if you don’t trust root).

It is all relative. If you are really paranoid, you don’t store the key on any machine that you don’t totally control. On the other hand, most people are prepared to trust that root has not been compromised and (as a fallback) that it requires some effort for someone with root access to break a keystore. An unlocked copy of your keystore in memory may count as “safe enough”. Certainly, a lot of user keystore software seems to work on that assumption.

Why should the directory be set to 0700? Even if it was 0777, a file inside it with 0600 would still be unreadable to others, right?

Partly general paranoia, partly belt-and-braces, partly a sign to other users to “keep your nose out of my private stuff”, and partly to protect against someone by replacing your key file. The last point could be critical … or not … depending on exactly how the key is used by your application.