Our great sponsors
-
age
A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
ssh-agent-pkcs11
A PKCS#11 module which uses certificates stored on remote systems accessed over the SSH Agent protocol
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
rage
A simple, secure and modern file encryption tool (and Rust library) with small explicit keys, no config options, and UNIX-style composability.
You wrote:
> This has literally nothing to do with age, which, by deliberate design, doesn't implement signing. What a strange and hostile thing to write.
But of course I never claimed age performs signing I wrote that it re-uses SSH keys without a safety rationale. Here's what age actually says about its re-use of SSH keys:
"As a convenience feature, age also supports encrypting to ssh-rsa and ssh-ed25519 SSH public keys, and decrypting with the respective private key file." -- https://github.com/FiloSottile/age#ssh-keys
So, we see age does in fact re-use SSH keys for this unrelated purpose. And we see that, unlike the OpenSSH feature described in this article, it offers no rationale for why this is safe. Filippo talked about writing such a rationale but ultimately there isn't one provided.
Ordinary users shouldn't try to imagine for themselves why something dangerous might be safe. In the absence of a rationale for why re-using your SSH private keys to decrypt age messages is OK, don't do it.
The article provides a rationale for OpenSSH's "sign arbitrary data" feature (a briefer one is included in the OpenSSH distribution itself) so that you can assure yourself that this is a reasonable thing to do.
> GitHub acts as a trusted third party here, and you have to trust them not to lie about people's public keys, so it may not be appropriate for all use cases. But relying on a trusted third party with a professional security team like GitHub seems like a way better default than PGP's Web of Trust, which was nigh impossible to use.
Hopefully that's a false dichotomy and the entire Free Software community doesn't end up reliant on Microsoft to host all our keys for us. The article goes on to mention key transparency, though, which does seem like the right solution.
I note that rekor (the transparency log implementation used by sigstore) already supports signing with SSH keys[0], so this TechRepublic article about it[1] from March (which lists only "GPG, x509 and Minisign") is already out of date.
[0] https://github.com/sigstore/rekor/blob/main/types.md#ssh
[1] https://www.techrepublic.com/article/a-new-linux-foundation-...
Ledger/Trezor have solved this since ~2016. I have a Ledger that has a private key inside and using a small open source tool (https://github.com/romanz/trezor-agent) I can SSH into machines, sign random data and Github commits and FIDO authenticate into several websites. All of that and knowing that these devices offer some of the best security out there.
It hasn't been able to do it in a meaningful way.
I've been patching support for this into ssh-agent for about a decade. I wrote a PKCS#11 module which talks to the SSH agent socket to forward your smartcard [0]. Doing so requires three changes to the protocol:
1. The ability to sign arbitrary data and get back the signed result [1]; normally you get back a hashed result [2].
2. The ability to decrypt data, this is what you said. This is less important since many things only require signatures (and not all algorithms support encryption/decryption).
3. The ability to request your certificates [3] [4] this one is kinda obvious.
The benefits of this are that you can use your smartcard on the remote host to do fully authenticated password-less sudo with pam_pkcs11. You can also do anything else that requires you to use your private key to be used, which can include fetching files (TLS client certificate authentication).
Within the US Government, passwords have been being phased out since 2004, but the requirements for authenticated privilege elevation remain.
Another way to accomplish this is to use SSH forwarding of your PC/SC socket but that's less portable and more fragile (and even less secure).
[0] https://github.com/rkeene/ssh-agent-pkcs11
[1] https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?l...
[2] https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent...
[3] https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?l...
[4] https://datatracker.ietf.org/doc/html/rfc6187#section-2.1
We've implemented a DID method based on this!
https://github.com/spruceid/ssi/tree/main/did-webkey
Yes it is, and they are awesome. git-crypt[0] is a godsend for smaller projects (and maybe larger ones if permissions are granular enough) -- way simpler than sops[1] and other alternative, with native integration via git filters (smudge). I use it on a ton of projects.
[0]: https://www.agwa.name/projects/git-crypt/
[1]: https://github.com/mozilla/sops
Yes it is, and they are awesome. git-crypt[0] is a godsend for smaller projects (and maybe larger ones if permissions are granular enough) -- way simpler than sops[1] and other alternative, with native integration via git filters (smudge). I use it on a ton of projects.
[0]: https://www.agwa.name/projects/git-crypt/
[1]: https://github.com/mozilla/sops
Bootstrapping is always a harder problem. But for updates, guix git authenticate [0] has definitely solved the problem. The idea is if you specify a certain commit that serves as a trust anchor, the .guix-authorizations file at that commit represents the public keys allowed to sign commits from that point: the file can be amended only by an already-approved key.
So if the repo has that file, and as long as you don't allow history rewrite when pulling (disabled by default), you can be pretty confident all commits have been signed only by authorized keys from the point you checked out initially.
About bootstrapping, several strategies are possible:
- [crev](https://github.com/crev-dev/cargo-crev) is an alternative (not PGP/SSH based) web of trust for vetting code
- [radicle](https://radicle.xyz/) is a p2p forge to do away entirely with web-based centralized forges (like github)
- we could imagine a sort of public-key-addressed DHT where a forge (such a Github) advertises the public keys of its members, for example based on IPNS (although a history-preserving system would be better)
- of course source-based distros like NixOS and GNU/guix are also a very good answer about bootstrapping trust in the code you run ; guix in particular does intensive research and development about bootstrappability and reproducibility [1] which you can read about on their blog [2]
Shameless plug: i wrote an article earlier this year about some of the challenges surrounding decentralized forging: https://staticadventures.netlib.re/blog/decentralized-forge/
[0] https://guix.gnu.org/en/blog/2020/securing-updates/
[1] I'm personally really amazed and slightly disappointed by both: they're really cool on paper, but although guix has a much better CLI UX than nix (and in my opinion Guile Scheme is much easier than nix programming language), both have very cryptic errors
[2] https://guix.gnu.org/en/blog/
[3] https://github.com/mlin/stakesign
Footnote: Bitcoin also had an arbitrary-message-signing mechanism -- commonly used on bitcointalk back in the day -- but I think it may now be ~defunct due to not keeping up with the newer address types introduced in recent years.
Related posts
- rage: A simple, secure and modern encryption tool (and Rust library) with small explicit keys, no config options, and UNIX-style composability.
- Tiny backup/encryption tool for CLI usage.
- "gpg: all values passed to '--default-key' ignored"?
- Dexios - a secure and open source command-line file encryption utility
- Dexios - a secure command-line encryption tool.