-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
YubiKey plugin #25
YubiKey plugin #25
Conversation
Codecov Report
@@ Coverage Diff @@
## master #25 +/- ##
==========================================
- Coverage 39.64% 32.85% -6.80%
==========================================
Files 24 33 +9
Lines 2023 2624 +601
==========================================
+ Hits 802 862 +60
- Misses 1221 1762 +541
Continue to review full report at Codecov.
|
462075e
to
65ad1ae
Compare
de4f7be
to
d21c9ca
Compare
a128496
to
0e16ffa
Compare
UX notes from demoing the current draft implementation to @FiloSottile:
|
Hey, a person looking for a simple encryption tool with hardware key support here – this looks like a great feature for an already nice tool. Is there a plan to support uploading existing keys to a YubiKey? Is it even possible? Here's my use case for this: generate a keypair on an airgapped computer booted from some live CD distro, then copy it to a YubiKey device and create a password-protected backup for storage on a usb stick for extra safety in case I lose or damage my hardware key. This way my regular machine never sees the private key yet I have it securely backed up just in case. |
@jstasiak yes, that can be done with |
That would be a very useful feature! Once the aforementioned refactor into a plugin has occurred, it will be much easier to support this kind of customized key setup for a particular recipient type. |
4376c5d
to
7258d07
Compare
BTW which YubiKeys this is expected to be compatible with? |
Any that support secp256r1 for PIV, and that the |
e2aa4ff
to
ad99744
Compare
Is there a specific reason this is blocked? Can I help? |
@gitirabassi This is currently blocked on the design of the age plugin system (which is how we are going to deploy this), because the recipient and stub formats will be changing as a result. I've reworked this PR locally on top of the draft plugin interface (#99), and the next step is exercising the plugin API and ironing out the kinks. |
e154c13
to
ad6e48e
Compare
YubiKeys are managed as age identities via a "stub" that indicates the slot to be used on a particular YubiKey. The stub can be placed alongside any age keys, and tells rage that it should attempt to decrypt matching YubiKey recipient lines.
Generates stubs for existing keys, and new keys for empty slots.
I've rebased this PR on #99, and this is now working as a plugin. However, it adds a default requirement for anyone building from the |
Migrated to str4d/age-plugin-yubikey#1. |
Discuss this draft on the age-dev mailing list thread!
Current draft specification:
age PIV identities use ECC P-256 keys, generated on the hardware token, with certificates that never expire.
For hardware tokens that support PIN and/or touch policies (such as YubiKeys), the default PIN policy is "once per session", and the default touch policy is "every decryption".
A PIV recipient has the following form:
where
SEC-1-C
is the 33-byte compressed SEC-1 encoding.A PIV recipient line is of the form:
where
ephemeral secret
is a random scalar within the scalar field of P-256 and MUST be new for every file key,salt
isSEC-1-C(ECDH(ephemeral secret, basepoint)) || SEC-1-C(public key)
, andlabel
isage-encryption.org/v1/piv
.A YubiKey "identity" is managed locally as a key stub with the following form:
The stub may exist in files alongside age X25519 secret keys, and is similarly passed to the age / rage binary with the -i flag.
Note that the common tag in the recipient line and key stub means that recipients can trivially identify whether they can decrypt a particular recipient line, at the cost of making recipients linkable across different encrypted files.
Usage example (responses out-of-date):