Currently the assistant sets up a shared encryption key, which is checked into git, so anyone who gets the repository can decrypt files that are stored encrypted on special remotes.

To support using gpg keys in the assistant, we need some things:

1. Help user set up a gpg key if they don't have one. This could be a special-purpose key dedicated to being used by git-annex. It might be nice to leave the user with a securely set up general purpose key, but that would certainly preclude prompting for its password in the webapp. Indeed, the password prompt is the main problem here. Best solution would be to get gpg agent working on all supported platforms.

   Update: For now, git-annex only assists in generating gpg keys that are intended to only be used to encrypt a repo.

2. After generating a gpg key, back it up. It might be the only way some data is accessible.

   One way I'm considering is generating a QR code of the key, which could be printed to paper. Preliminary results are good; a 4096 bit secret key fits in a QR code (a secret key with many subkeys may not). Debian has command-line utilities that can generate and read such a QR code.

   Another way would be to use shamir secret sharing to split the key into N peices and send each one to one of the user's repos.

3. Help user learn the gpg keys of people they want to share their repo with, and give them access. If the public key was recorded in the git-annex branch, this could be easily determined when sharing repositories with friends. Or, use MonkeySphere, or Monkeysign..

---

Another gpg key security thing is that currently git-annex stores crypto creds in memory while it's running. Should use locked memory. See https://github.com/vincenthz/hs-securemem and https://github.com/vincenthz/hs-securemem/issues/1