age and sops
joe-getcouragenow opened this issue · comments
sops now supports age, which can be used instead of pgp.
age is cross platform.
Hello,
Thanks for letting me know about age. I will take a look at it !
While we are giving erebe unsolicited advice... (love your setup btw! referencing it for some other work)
I would discourage 'age', 'signify', 'crev', 'keybase', and similar knee-jerk "we need a better gpg!" alternatives that all naively insist on keeping private keys in system memory where malware could potentially obtain them.
GnuPG for all its usability faults is still the only suite in this class of tools with strong support for smartcards (Trezor, Ledger, Yubikey, Nitrokey, etc etc)
There are almost no reason for a human-held key to exist outside a cheap secure enclave today.
https://sequoia-pgp.org/ is the only reasonable alternative that looks like a potential successor for the use cases and threat profile GnuPG supports, but only after smartcard support merges.
@lrvick age works with yubikeys: https://github.com/str4d/age-plugin-yubikey
rage is the rust version
- he is the original issue: str4d/rage#16
age is the golang version
https://github.com/FiloSottile/yubikey-agent
they are interoperable.
Judging by the state of the default branch, the 'age-plugin-yubikey' looks like it has some work to go:
https://github.com/str4d/age-plugin-yubikey/blob/main/src/main.rs
Judging by the development branch, it is hardcoding support for a specific product, Yubikeys, instead of a mature spec like FIDO2 or https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.pdf
Dozens of hardware products support the OpenPGP smart card specification. By supporting that, one supports all the existing hardware that implements it along with all the features needed for real world use like expiration, key distribution, identity proofs, peer verification etc.
The yubikey-agent repo is likewise a one-off that does not comply with a spec implemented by any hardware other than yubikeys, and requires a custom ssh agent to use.
If all one wants is a tap of a hardware token for ssh login, the FIDO2 specification is natively supported in SSH out of the box and works with Yubikeys as well as dozens of other hardware U2F/FIDO2 products that exist with no additional software. OpenSC support exists with ssh out of the box too and also supports SSH via any OpenSC compatible device including yubikeys via PKSC#11. I honestly don't know why the dozen or so alternative ssh-agent solutions that talk to yubikeys exist. I can only assume they didn't research any of the existing options, or just wanted to do it for fun and not seriously intending to solve a new problem.
Having two standalone binaries maintained by two different individuals one needs to hand review/compile from unsigned source code to do what GPG and SSH already supports out of the box is a confusing choice. There are also no signed package of it in any major package manager, let alone reproducible built ones.
Age does not even sign its commits or sign its own binaries, and recommends just building from an unsigned code by hand, or installing with brew (which also doesn't do signing), but bills itself as a secure crypto tool. Filo and Ben are amazing software engineers, but I really don't know what they are thinking with software supply chain integrity in this project, let alone what new problem it is solving other than being a fun experiment. Fun experiments are fine, but don't let people believe they have comparable security to existing highly visible, implemented, and reviewed solutions. :/
But I digress...
IMO abandoning (or distracting from) OpenPGP and the huge established ecosystem that supports it because GnuPG is a poor implementation of it is like abandoning HTTP because IE sucked. What was needed were people willing to make the spec better, and make better browsers.
With the exception of perhaps notary, which implements the TUF spec and solves problems OpenPGP was not designed to solve, all these recent alternative one-off hobby crypto experiments devoid of any real ecosystems, standards bodies, auditors, signed packages, formal carefully reviewed specs, etc should not be seriously recommended for real world use. I worry popular best-practice repos like this one implementing it will only further this cowboy crypto trend. Sops implementing age is the most disappointed I have been in a widely useful software package since Terraform implemented keybase.
Making established specs work well is hard enough without people running off and making up new crypto solutions from 0 on their own without seriously researching the existing options and ecosystems and clearly identifying specific problem in those specs that a new revision or better implementation can't solve.
Just my long winded 2c since you seem to care about this subject matter and might benefit from a different perspective from a security engineer who spends most of his time integrating, auditing, designing, and engineering HSM solutions.
I'll refrain from hijacking this thread more than I already have but reach out any time if you want to discuss this sort of thing further!
@lrvick
you said "IMO abandoning OpenPGP". I am have not and am not suggesting this be done.
I am only suggesting that age can work with gopass as a 2nd option for people :) PGP is unaffected.
the hope is then that with age working with gopass and other tools, then it will be easier and more useful to then work on the hardware token aspects.
I get what you are trying to say.
I just want to double down on the point that we should not be encouraging any project to support nonstandard insecure crypto projects just like we should not encourage browsers to implement nonstandard features. Adding insecurely distributed dependencies just makes every project that includes them less secure too. This bolt-on alternate implementation story is how we end up with ActiveX and Flash which were a huge distraction from improving the actual specs of the web.
IMO we need to funnel everyone to using and understanding existing formal spec driven ecosystems like OpenPGP and TUF, so they will help invest in building up secure and broadly useful mature implementations and spec improvements.
Crypto is hard enough without adding even more fragmentation and divided auditing attention to the space for things that don't clearly solve any new problems.
I got a chance to take a look at age and well, I am going to side with @lrvick, even if I have less arguements 😄.
It seems to me that age does not bring much value beside saying, fuck it gpg, I am going to roll my own in a simpler way.
Even if the project seems successful in doing that, it lacks a lot of 3rd party integration, as mentioned by @lrvick
I prefer to not introduce age and let people create their gpg/pgp key, by doing that and if they want, they are a step away from being able to:
- Sign/Verify their commit in git
- Able to sign their release/tags/artifacts
- Buy a YubiKey for hardware key ...
- Publish their public key into GPG repository for people to import it
- Encrypt their email
- ...
GPG is well known and has a well-supported ecosystem, so I don't feel the need to introduce age in this tutorial
P.s: Added a mention in the Readme of signing your git commit with gpg key
Ok no worries.
TUF is great. currently use it.
will close this one...