Allow extracting bulk encryption symmetric key and using it for decryption

[hardfalcon]

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.

[str4d]

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:

• On the local machine, a binary that has access to your age identity.
• On the server, an age plugin for a custom remote identity.
• On the server, a daemon that acts as a bridge.

Setup flow:

• Run the daemon on the server (or alternatively it could be run by the plugin, with some timeouts
• Use the local binary in setup mode, to generate a remote identity that points to your local age identity (but contains no private key material).
• Move the remote identity to the server.

Usage flow:

• Run the local binary in operation mode; it connects to the server daemon (via an SSH connection or some other authenticated pathway).
• Use 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.

[FiloSottile]

Yeah I think this kind of use case is a perfect match for plugins.

In fact, shouldn't this work out of the box with an agent plugin and the equivalent of SSH agent forwarding?

[hardfalcon]

str4d: Sorry, but how could I use such a plugin? I have searched the age repo here on github, and I couldn't find any information/documentation on how to write a plugin for age, or even just how to use such a plugin if there was one, and neither age --help nor age-keygen --help seem to give any hint about plugins at all. Since your own rage repo seems to contain an example plugin, is your answer specific to rage?

FiloSottile: SSH agent forwarding is precisely what I want to avoid because there's no way for me to tell on my local machine what exactly the remote server is asking my agent to sign or decrypt, and most people don't even use the the -a flag of ssh-add at all. In fact, because agent forwarding is considered harmful and dangerous, I routinely forbid its usage on all my servers. For all I know, even if my local key agent asks me for permission to use my key, I won't be able to tell if the remote server is having my agent help decrypt a backup file, or if the remote server has been compromised and is trying to abuse the forwarded agent to log into my local machine. Hence I'd very much prefer to avoid using agent forwarding if possible.

[FiloSottile]

Plugins are not stable yet, so there are no docs or usable plugins available at the moment, however this use case will be a good fit for a plugin once they are ready.

To be clear I didn't mean actually SSH agent forwarding, it wouldn't work and I agree it's not safe, but the equivalent UX for a future age agent. I think the risk of swapping what file is getting decrypted is unavoidable if you don't trust the machine where the file is.

[stsch9]

I have a similar use case as @hardfalcon: I want to add and remove recipients without decrypting and re-encrypting the whole file. i.e. I only want to decrypt the file_key alone and re-encrypt it with different recipients. This would be a nice feature. At the moment I don't see a way to do this.

[FiloSottile]

Can I ask a bit more about your use case?

Adding and removing recipients can’t be done in place because it grows and shrinks the header, so copying the payload is unavoidable. Symmetric encryption is pretty fast (and we might be able to make it even faster), to the point it might not be meaningfully slower than the copy itself.

[stsch9]

Thanks for the quick answer!
My Use Case: I want to store data in a cloud storage (like dropbox). I create a group key (X25519 private key) for a group and encrypt it for all recipients of the group who should have access to the files. (I like the idea signing the header with HMAC and the file key). All files are then encrypted with this group key using age. If a new recipient is added, I only have to encrypt the group key with the public key of the new recipient. This is not a problem.
However, if a recipient is removed, I also have to change the group key. Therefore, I must also encrypt all files with the new group key and remove the old group key. Therefore, it would make sense to re-encrypt only the file keys of the files and not all the files.
Is this possible with age or do you think this is a stupid idea?