Closed Kranzes closed 2 months ago
@Kranzes Thanks for the question/suggestion! I think the direct answer to this question might unfortunately be no. The problem is that age spawns a new plugin process for each decrypted file and afaik there's no "bulk mode" where one plugin process unwraps all file keys. So the caching would need to survive subsequent process calls, which is hard to realize in a secure way. There would need to be something like a fido2 agent running that caches the pin, and I don't know any existing that would be capable of that.
In case you have a yubikey (series 4/5, not fido2-only) I'd suggest to try https://github.com/str4d/age-plugin-yubikey where this might work better compared to here because it uses piv slots (with more advanced pin/touch policies).
As for this plugin: I could theoretically add a flag like --export-x25519-identity
which let's you export a native x25519 identity (for a specific fido2-hmac recipient/identity). Then this could be used without any user interactions for decryption. I am not a huge fan of this since it'd expose the private key that is protected by the fido2 token in a way it was originally not intended. On the other side, it might be a useful thing (with big warning signs) for users like you for temporary bulk decryptions in a secure environment or as a backup.
Please let me know your thoughts on this.
I already use age-plugin-yubikey and was considering switching to age-plugin-fido2-hmac, but I guess I will stick to age-plugin-yubikey.
Is it possible to implement a caching mechanism for the PIN so it doesn't require you to enter it every time if you are decrypting files in bulk?