Releases: olastor/age-plugin-fido2-hmac
v0.2.3
v0.2.2
fixes
- Release binaries were all using linux/amd64 as os/arch. Now they should be built properly (thanks @highesteem for noticing, see #12). Due to the go-libfido2 dependency not supporting all previous os/arch combinations, only darwin and linux are for now in release binaries (Windows is removed because I don't have the time to figure out some Windows commands for the CI right now).
- update go-libfido2 dependency to a newer commit since the latest release doesn't include a fix for building on mac os (keys-pub/go-libfido2#38). Also related to #12 .
chore
- update some Github Actions versions
- Explicitly set CGO_ENABLED=1 when building
docs
- improve install instructions in README
v0.2.1
v0.2.0
tldr; no more inserting the fido2 token for encryption for new recipients (-g to create new ones); old format still available (--symmetric -g); backwards compatibility with v0.1.x; everything uses go instead of python now.
Please note this is still v0.x.
show full description
Major Spec Changes
(see here)
In order to realize #10, the specification needed to be changed siginificantly enough that I consider this to be a new major version (v2). However, it's still possible to use the old version v1 by creating new credentials with the additional --symmetric flag. Plugin operations should work for both versions. The reason for not abandoning the old format is because it might still be a valid use case to generate a new salt / credential for every encryption (with the downside of having to present the token). The new format needs to use a fixed random salt per recipient and not per encrypted file, but it uses the hmac result not as a symmetric key, but as an x25519 private key.
Basically, the 32 byte hmac output retrieved from the token is now used as a native age identity (but the private key is only temporarily kept in memory when it needs to be used). Thus, recipients are also native age recipients if the user is fine to securely store an additinal identity string. Otherwise, it's still a plugin identity (that also includes the public key).
The two different formats of recipients / identities are now a bit more formalized by discussing "security goals" vs "UX goals".
Complicated routines for selecting which token to use in scenarios where multiple are selected have been removed. This would be a "nice to have" extension that may be added in the future, but for now the core functionality is more important.
Go instead of Python
Rewriting everything from scratch in Go had two main reasons:
- The new spec is written so that wrapping of the file key can be delegated to the existing native age methods
Wrap/Unwrap. This prevents any mistakes that might happen if I would reimplement the cryptographic operations done in these methods. The Python bindings do not exposeWrap/Unwrapand for maintainability it's also preferred to use the original library directly. - In the other plugin I wrote (age-plugin-sss) I spent quite some time to create helpers for the plugin state machine. I don't want to maintain two different implementations of this in multiple languages. By switching to Go it's possible to reuse the same code, which I might even split into a separate package in the future to have cleaner dependencies.
Misc
- There are now e2e tests, but I haven't found a way to include them in the CI because it'd require usbip to work somehow. They should not be run with a real token, but only with the virtual test device (see README).
- Improved help message
- When a PIN is required multiple times for the same device, it now only needs to be entered once.
- Experimental use of
mlock()on unix to prevent swapping the secret to disk. This is not fully consistent yet since the identity based on the secret is not (yet) mlock'ed.