Just a note, but it seems that the correct thing to do for
any systems that can keep logs, is to have a configuration
choice so the logs can be kept in encrypted form, or not
at all, or in cleartext.
What you cannot do with security is encrypt the logs *after*
they hit the disk in cleartext -- because then there's a
cleartext copy of them *somewhere*, *sometime*. This is a
substantial problem, especially in a context where the
machine might be stolen.
What you also cannot do with security is use a straightup
symmetric-key system to encrypt them. Then the application
would have a copy of the key -- which could also be used
for decryption. If it's a public/private key pair, the fact
that the application may have a copy of the key used for
encryption does not give any hints of a key to use for
decryption, even if someone can inspect its binary image.
So the thing-that-keeps-encrypted-logs pretty much has to
use a public-key system to do it. Maybe it generates and
saves (encrypted by the public-key system) a new symmetric
key every ten kilobytes or so -- that way you could use the
faster symmetric-key algorithms for the bulk of the log
without a loss of asymmetric-keyed security, and if someone
does pluck the key out of the binary image, they get ten
kilobytes of the log, or less.
If you can keep the private log key in your head, you can
know that nobody can read the damn logs without your help.
Sounds like a good library to implement.
Bear
