git-chat-read: cache decrypted messages in AES-encrypted cache

[brandon1024]

A drawback of RSA encryption is the computation time needed to decrypt messages. When reading messages with git-chat-read, it takes a while to decrypt messages and write them to output.

One way to solve this problem is to cache decrypted messages locally, but encrypt them with a faster algorithm like AES. When messages are being read, git-chat-read could invoke some appliance (gc-fast-cache, or similar) that stores those messages for fast lookup later. The message cache could be keyed by commit id for easy lookup, and the cache could have a similar format to the git db (.git/chat-cache/objects/FF/ABCD...). When reading messages, if a message is cached with that commit id, it is quickly decrypted with the user's password, otherwise it is decrypted with their GPG key.

This raises the question of how we would manage the AES cache password. Can we leverage GPGME somehow?

The cache should also be an opt-in model. This is easily accomplished with a config option.

[brandon1024]

GPG supports symmetric encryption with GPG private keys instead of passphrases. This is great because it allows us to encrypt a message with a fast algorithm like AES and decrypt the message with the same key we use to read asymetrically-encrypted messages. We won't need to prompt for two passphrases (one for symmetric, one for asymmetric)!

So in the end, this should be fairly straightforward to implement. When a message is decrypted, we will encrypt it symmetrically with our public key and store the ciphertext in the cache (with only one recipient, ourselves).

[brandon1024]

Another consideration is what commands will trigger a cache-write operation. Do we only cache messages when git-chat-read is invoked? I think that's probably a good idea. Alternatively we could trigger gc-fast-cache every once in a while against all git (commit) objects in the git db, but I'm less fond of this approach.

We should also consider garbage collection. Although it's probably not a big concern (I can't imagine users will manipulate the history often), we should keep in mind that the cache could grow very large if we don't prune unreachable messages. Maybe we could add a git-chat-gc builtin that the user could use to clean the cache manually. It might have a synopsis like this:

git-chat-gc [--clear-db]

[brandon1024]

I've been doing some testing to see if GPG would be performant enough for our needs, and it looks like it won't be. It can take ~45 seconds to decrypt 100 messages, whereas with OpenSSL it takes ~0.5s.

Additionally, I'm still trying to come up with a way to obtain the cache password. I don't really want to deal with pinentry, I'd prefer the password come from a keystore like the GPG agent. Still thinking on this, I wager it'll take a while before I think up a solution.