in reply to Re: Re: Cryptography Best Practices
in thread Cryptography Best Practices

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.

  • Comment on Re: Re: Re: Cryptography Best Practices

Replies are listed 'Best First'.
Re: Re: Re: Re: Cryptography Best Practices
by Ryszard (Priest) on Nov 12, 2002 at 15:54 UTC
    This is a cool idea. Each time you start up the daemon process you must type in the key. The Daemon then acts as an API to the files in the filesystem. If you wanted to get tricky, you could then start caching the encrypted/plain text files (depending on your security requirement) in memory for faster access...

    I like this idea for a few reasons:

    1. The key is not stored anywhere except in memory
    2. The api then becomes extensible such that you can add extra functions such as change_key.
    3. All the logging can be done implicitly by a framework that is in place.

    On the downside tho' there must be a human nearby who can enter the password each time the daemon process is stopped, crashes, the machine goes down etc, etc... Also the key may get paged out at some point...