Well, I'm surely not claiming my approach here is particularly general, but I'm working with a large system that's been around for over 20 years, so it has accreted considerable mass and inertia. It already uses kerberos, and the model: producer -> [circular file transaction buffer] -> consumers is fixed. So, the fact that I can do what I need in 100 lines of code or so on each end, and come up with it in less than a day is a good thing.
John > If you're writing the data into a file, maybe just encrypting it with the > key from a "keytab" would be sufficient - e.g. using gpg in symmetric mode > and read the passphrase from a file (or gpg with pub/priv key, reading the > priv key passphrase from a file). As you say, anyone who can read the > keytab can also read the data, but that's going to be a fundamental > limitation of your design anyway. Ultimately, each process is going to need > credentials suitable for decrypting data written by the other process, > otherwise it can't work, and it has to get those credentials from somewhere. > > A few alternatives: > > 1. you store those secret info in the filesystem or in the application > itself (which makes it readable to anyone else with sufficient privileges) > > 2. you prompt for it when each process starts, and keep it in RAM (which > means restarts require manual intervention) > > 3. you have a parent-child relationship between the two processes: process A > can think of a random key, fork, and process B knows the same key. This also > keeps it in RAM only, but any existing files on disk will become useless if > you restart the processes. > > 4. you use some sort of hardware approach like TPM or a crypto module - but > even then, you have to make sure that only processes A/B can ask the module > to decrypt the data, which brings you back to the same problem. You could > perhaps run the two processes in separate VMs, and communicate via a shared > filesystem such as NFS. > > 5. does it really need to go via the filesystem? Could you use TLS over a > socket instead? > > Just a few thoughts. > > B. > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
