age: Integration with OpenPGP Card without a Plugin

[jht5945]

From YubiKey firmware 5.2.3 (https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements_to_OpenPGP_3.4.html), X25519 is supported.

When we use X25519 keys in OpenPGP, we can write private keys to a OpenPGP Card(e.g. YubiKey), If we do so, we can protect the private keys with hardware.

We can use the same key pair in age, and this will bring us hardware protected feature with out a plugin.

For OpenPGP Card, send below command to the card via PC/SC:

CLA: 0x00, INS: 0x2A, P1: 0x80, P2: 0x86, DATA: A6 7F49 86 EPK

The we will get the shared secret, and then the age file can be decrypted.

Although it will work, but when we have multiple recipients, I need to try all the X25519 recipient stanzas with OpenPGP Card. But OpenPGP operation is verify heavy, it requires PIN and a touch(If turn the policy on).

So if we want to support OpenPGP Card protected age encrypted files, we need a quick lightweight way to verify X25519 recipient stanza, my suggestion is that add an additional argument to X25519 recipient stanza.

Current X25519 recipient stanza is like this:

-> X25519 1R1xhye2ff90kBDpmIlhKAd9R/uyMJPn2U1y5YfjBl4
jerzVNLKbmFn56WxRBlGZ3otYMUwR29Pcml+WzU36Is

Then change to:

-> X25519 1R1xhye2ff90kBDpmIlhKAd9R/uyMJPn2U1y5YfjBl4 RECIPIENT
jerzVNLKbmFn56WxRBlGZ3otYMUwR29Pcml+WzU36Is

RECIPIENT can be Hmac_SHA256(recipient, ephemeral share), with this additional argument we can confirm which recipient is correct quickly.

[str4d]

We can use the same key pair in age, and this will bring us hardware protected feature with out a plugin.

It won't avoid a plugin for decryption, because that is how the OpenPGP Card integration would be implemented. But it would avoid a plugin for encryption.

So if we want to support OpenPGP Card protected age encrypted files, we need a quick lightweight way to verify X25519 recipient stanza, my suggestion is that add an additional argument to X25519 recipient stanza.

We cannot do this for the v1 age encryption format, because it violates a MUST requirement:

X25519 recipient stanza

[...]
The identity implementation MUST ignore any stanza that does not have X25519 as the first argument, and MUST otherwise reject any stanza that has more or less than two arguments

It might be worth considering for a future v2 format though.