age encrypt for YubiKey PIV
Encrypts one secret to the recipients you list below. This page cannot decrypt, makes no network requests and stores nothing.
Recipients
Secret
Output
Decrypt outside the browser: age -d -i IDENTITY-FILE LABEL.age
How this uses a YubiKey
There are two ways to encrypt with a YubiKey. This page does the first and not the second.
PIV, as used by age-plugin-yubikey (this page). The YubiKey holds a P-256 private key in one of its PIV slots. The plugin had the YubiKey generate that key on the device, and PIV has no command to read a private key back out, so it has never left the device. What you paste above, age1yubikey1..., is only the matching public key.
- Encrypting needs the public key and nothing else. The YubiKey does not have to be plugged in, and nobody is asked for a PIN or a touch.
- Decrypting needs the YubiKey itself, its PIN and a touch, because the private-key step runs inside the device. A browser cannot talk to the PIV side of a YubiKey, so this page could not decrypt even if it tried. That is done with
ageandage-plugin-yubikeyin a terminal. - So a page like this one, even a tampered copy, can see a secret while you type it but can never read back the ones you already encrypted.
WebAuthn PRF, also called FIDO2 hmac-secret (not this page). Here the browser asks the YubiKey to derive a secret key from a credential, and the YubiKey hands that key to the web page. The page then encrypts and decrypts with it.
- It is one shared key, not a public and private pair, so the YubiKey must be present and touched to encrypt as well as to decrypt.
- The credential stays on the device, but the derived key is given to the page. Any page that can encrypt this way can also decrypt, and so can whatever else is running in that page.
- It is more convenient, since everything happens in the browser. It is also why this page does not offer it: the point here is that the browser never holds anything that can decrypt.