Only if people can get at the data. If you're that paranoid, keep the data on removeable media (e.g., a USB keychain), and only use it on computers that aren't connected to networks.

In real life, what is the best way to store your key?

In your head, if the key is short.

maybe i should describe a bit more of what is going on. the script will have to add data, encrypt it, and write it to file from non-privelaged people (over a web page). the *only* thing in this entire system that i want to have privelaged access (that is, unencrypted access) to all the data is the system itself (and possibly auditors).

the problem that i am combatting is two-fold: data integrity and non-repudiation. i am trying to prevent people from being able to change data, and if they do change data (or add data) they will be logged in a secure way.

does this make sense, or should i be going about this a completely different way?

The only way that you can avoid storing the keys in the file system is that the program needs to be started interactively by someone who knows the key (password).

Since you probably want others to be able to run the program (either via web or command line), what you have to do is make one program be a front end to a daemon process which runs continuously and holds the key in memory (in a variable). This is quite non-trivial since you then have to make (and authenticate) connections to the daemon.

Although people (on slashdot, especially) like to point out the possible DRM abuses of TCPA and Microsoft's Palladium, it does have legitimate uses like solving this difficult problem.

the problem that i am combatting is two-fold: data integrity and non-repudiation. i am trying to prevent people from being able to change data, and if they do change data (or add data) they will be logged in a secure way.

For access, you could combine SSL (https:) and Basic Authorization. That, coupled with logs, can give you a record of who changes what. You're still relying on your end users to not leak (or share) passwords.

On the server side, if you want the system to have unencrypted access to the data, you have to decide how to handle your keys. A worst-practice is to embed keys into scripts. This can be bad because every so often an exploit appears that lets users see script source.

A somewhat better practice is to place keys in a configuration file that isn't visible to the web server (i.e., in a file that can't be reached via a URL).

In real life, what is the best way to store your key?

as dws said, in your head is best. i might use a sentence, line of poetry, or perhaps a spelled out date, with extra characters somewhere inside, and hash it with MD5. if you make the MD5 hash the key, and generate it as part of the key entry process, you need only remember the input that generates the actual key, which is usually much easier to remember than the key itself.

~Particle *accelerates*

I found this node really interesting: Encrypting Credit card numbers. If I understood correctly, you should not store your valuable data on the same machine connected to the outside world. In that node you will find many interesting and useful discussions about many related topics.

Probably you will need also some kind of versioning of your data. For the non-repudiation part, you may find interesting this link: Non-Repudiation in the Digital Environment

HTH, Valerio

Hi, on a 10 meg text file, I would use the "crypto filesystem" to encrypt it. Then all writes to it will be transparently encrypted and you only need to give the key at boot time or when you need to restart the "crypto filesystem". Basically your text file will get mounted via a loopback device as it's own file system. I guess you could get around the password problem, by having yourself paged when there is a failure, and then ssh in to restart the crypto filesystem. Maybe you could even automate that part of it, and at least keep the password on a separate machine. Otherwise, you best bet is just to obfuscate the passord. Hide it in some binary file, and use some obfuscated way of extracting it, so at least a hacker will have to really work thru a bunch of files to find it. It really isn't too hard to hide something from the casual hacker.