It's Now Possible to Sign Arbitrary Data with Your SSH Keys

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • OPS - Build and Run Open Source Unikernels
  • Scout APM - Less time debugging, more time building
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • GitHub repo age

    A simple, modern and secure encryption tool (and Go 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." --

    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 repo rekor

    Supply Chain Transparency Log

    > 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.



  • OPS

    OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.

  • GitHub repo

    A ssh server that knows who you are. $ ssh

  • GitHub repo trezor-agent

    Hardware-based SSH/PGP agent

    Ledger/Trezor have solved this since ~2016. I have a Ledger that has a private key inside and using a small open source tool ( 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.

  • GitHub repo ssh-agent-pkcs11

    A PKCS#11 module which uses certificates stored on remote systems accessed over the SSH Agent protocol

    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).






  • GitHub repo ssi

    Core library for decentralized identity.

    We've implemented a DID method based on this!

  • GitHub repo git-crypt

    Transparent file encryption in git

    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.



  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • GitHub repo sops

    Simple and flexible tool for managing secrets

    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.



  • GitHub repo cargo-crev

    A cryptographically verifiable code review system for the cargo (Rust) package manager.

    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]( is an alternative (not PGP/SSH based) web of trust for vetting code

    - [radicle]( 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:


    [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


  • GitHub repo stakesign

    Sign files via blockchain + put your money where your mouth is


    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.

  • GitHub repo yubage

    `age-plugin-yubikey` implementation, encrypt things with a Yubikey/any PIV card

  • GitHub repo rage

    A simple, secure and modern encryption tool (and Rust library) with small explicit keys, no config options, and UNIX-style composability.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts