Closed hardfalcon closed 3 years ago
An alternative way to implement this use case would be as a plugin. It would be similar to a daemon plugin, and have several components:
remote
identity.Setup flow:
remote
identity that points to your local age identity (but contains no private key material).Usage flow:
age
to decrypt files on the server. The age plugin connects to the daemon, which ferrys its decryption requests to the local machine (which could have some confirmation process that authorizes decryption, or e.g. be hooked up to a YubiKey requiring a touch).This is basically the same approach (the plugin protocol effectively ships the header from age
to the plugin, and returns successfully-decrypted file keys from the plugin to age
), but the crypto is insulated from the user, and the user experience could likely be significantly better.
IMO it would be beneficial if age allowed extracting the symmetric key that's used for the bulk encryption, and using that key to decrypt an age encrypted file.
My use case for this feature is restoring backups that are dozens to hundreds of gigabytes in size on a remote server, where I do not want to make my private SSH key available to that server. I could work around this by encrypting the backups to an additional key pair that can be shared with the otherwise untrusted server for backup restore purposes, but IMO that would negate some of the desirable security properties of encrypting to the public SSH keys of the server administrators.
My expectation would be that with this feature, I could simply download the age header of the encrypted file to my laptop, use age to extract the symmetric encryption key using my private SSH key, and then use that symmetric key to decrypt the age encrypted backup file on the remote server.