Proposal: Adding support for key encryption with age

[tarnacious]

In a discussion on Twitter, @AGWA suggested he'd be interested in support for key encryption with age being added to git-crypt. I offered to work on a proposal.

The motivation is to support an alternative to PGP for encrypting the file encryption key for different users. Adding support for age would allow the keys to be encrypted and decrypted with age X25519 key-pairs or with SSH key-pairs.

I see the requirements of the feature like this:

• It should be possible to encrypt the key for a user with an X25519 or SSH public key
• The user should be able to unlock the repository with the corresponding private key
• The key encryption and decryption should use the age binary installed on the system
• No existing usage of git-crypt should be impacted.
• The new key encryption mechanism should work on existing git-crypt repositories.
• It should be possible to have PGP and age encrypted keys in the same repository.
• The UX for adding a new user and encrypting the key with age should be a new command, but should be similar to adding PGP users
• The UX for unlocking a repository should be very similar how it currently works. It should not require a new command.
• It should support pinentry for password protected private keys

An example workflow with an age key would look something like this:

collaborator# age-keygen -o mykey
Public key: age1jqew6srhcd5fzqfgmfgqjpy2n8sy7ahu2hy89da8807q7v6ez3zsjgqh5q 

maintainer# git-crypt add-user age1jqew6srhcd5fzqfgmfgqjpy2n8sy7ahu2hy89da8807q7v6ez3zsjgqh5q
[main 5d3e670] Add 1 git-crypt collaborator
 2 files changed, 4 insertions(+)
 create mode 100644 .git-crypt/.gitattributes
 create mode 100644 .git-crypt/keys/default/0/age1jqew6srhcd5fzqfgmfgqjpy2n8sy7ahu2hy89da8807q7v6ez3zsjgqh5q.age

collaborator# git-crypt unlock /path/to/mykey

An example workflow with an SSH key could look something like this:

maintainer# git-crypt add-user "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDZpelSSFyy7OqJJvMe3D6u4aHUxWE8kSR1hnFkcRMcXaIVRbTX/fK3zDPPIfLEJUOFj78IUKU2XkrANnZHMU8YtbSV33Nrw/b8qZjJnS0naT4S5HQArMrVkqZnP9L3j/uYnny/eJ/pkhwZXaD2UsbEH7kQ6ly9jwsqpVsm+OVg7C5zMv4YSrSF8WE0/ygb/WlIw7ecZ4fgiVk6APPYNviHkhICLMPLO9cPpfrMTZ+9bAFPjiOf1JLOfS+CxYzG9P+YgY+IRKTBeUfJwDyn5z/SjeUJM2fMhWQ32hOYLgRxSOvSV2FZyfwRh77K4l7idpxEIzDCx5d7aaXV9nN5O2AzGnqUKptICad2/xiYOengW3IIjBr2QkaG09RCahqGBpkeiCkUeQqLekwgs4N0KllQ8wwJjMyc24cyKo8cUFT2s63NplC01XLbcAQYotVfQEaCCSnDbjoVnGqZdOFFm41Oa8Aj5FIJ2Shv1oq2C8XgiPD5zxLPloFqZonqG/K89aU= tarn@tarnbarford.net" 
[main 5d3e670] Add 1 git-crypt collaborator
 2 files changed, 4 insertions(+)
 create mode 100644 .git-crypt/.gitattributes
 create mode 100644 .git-crypt/keys/default/0/tarn@tarnbarford.net.age

collaborator# git-crypt unlock
Enter passphrase: ********

There are some details I'm still considering, some that I need to investigate further and probably some that I'm missing.

A question that I haven't completely worked out is if there should be an option to provide a name for the key when adding a user. SSH public keys can be quite long and are not ideal to be used as part of a filename of the encrypted key. SSH public keys have the option for a comment after the key which could be used or even required as a name for the key. A name could also be useful to specify which encrypted key should be used to unlock the repository.

In the second example I assume it's possible to somehow use the ssh-agent to get the private key and pinentry just works. I assume this will be possible and additionally providing a path the to private key should be supported.

Support for encrypted age private keys should just work, I think, as long as the age pinentry works to enter the pass phrase.

I'm not sure if the full public key should be stored, I don't think this is needed now, but if it were possible to create a new file encryption key then being able to encrypt it for existing users might be useful.

I've also considered if it makes sense to support using a script to get the key. This can be useful for getting the key from the system key-chain or from a program like pass. This could also be added later.

I'm happy to do the work to create a pull request to implement the feature, but before starting that I'd like hear on any feedback on this proposal to make sure it's in the right ball park and adjust it if needed.