Sign arbitrary data with your SSH keys

>Here's why I like SSH signatures:

>* It's not PGP.

The most important reason people use the OpenPGP message format is because it is a well accepted standard. Sure the cryptography is not new and fun but it is secure. If you sign something with OpenPGP then you can be sure that those signatures are verifiable on any platform by anyone. The OpenPGP standard has provisions to ensure that the signatures are from a particular entity. This proposal suggests that Github could be treated as a trusted third party. If that is the case then you don't need signatures at all.

Obligatory "The PGP Problem" rebuttal:

* https://articles.59.ca/doku.php?id=pgpfan:tpp

> The OpenPGP standard has provisions to ensure that the signatures are from a particular entity.

No, it does not - it has provisions to ensure that the signatures are from a particular private key. Mapping that to a human-meaningful entity is beyond the scope of the OpenPGP specification.

The article you link does not really address that point, and it doesn't at all substantiate the claim that using GitHub as a trusted third party means you "don't need signatures at all".

(Also, the original post says that other means like key transparency can be used instead of trusting GitHub.)

Well, if you trust github enough for the keys, you can just download and distribute the arbitrary data through github itself. I guess that is what he was referring to.

As people can discover from the search bar on this site, your argument against that blog post (which I co-wrote) includes the notion that authenticated encryption is bad, because unauthenticated encryption creates opportunities for data recovery. Restating for the record: I agree in part; where we part company is that I think creating opportunities for data recovery for adversaries is a bad idea.

At any rate: this comment thread is about signing with SSH keys, not your idiosyncratic response to my blog post.

Isn't the web of trust part of a PGP? That maps private keys to human-meaningful entities. Or is that not part of OpenPGP?

The argument is that the whole "web of trust" thing never really took off, so you can't rely on it in practice.

It's one way to use PGP, and it's not the only way. Almost certainly the most common use of PGP by number of operations per day is verifying RPM and apt signatures, which relies on trusting specific keys delivered through out-of-band means (in practice, mostly previously delivered via HTTPS).

In turn, the subject information in these keys does not matter - either the signing key is trusted, or it's not. There's an ongoing philosophical debate among users of the web of trust about what the subject (name and email) means. Should you sign a key if you see a passport Are you attesting to legal names? If someone works via a pseudonym, how (if at all) should you sign their key? How do you validate the passport? Maybe you should only sign keys for people you actually know, and attest to knowing their identity in a human sense and not to them having legal documents? What about the email field - do you need to verify that they possess the email? How?

The OpenPGP spec includes just enough functionality to encode trust into local keys (and specifies that it should not be exported), but it does not say anything about a web of trust: https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3....

I don't think they're being idiosyncratic. You start your post off with a paragraph that complains about how bad PGP is. Of course people will respond to that part.

I don't think PGP is that bad either. It's pretty standard asymmetric crypto. The implementations and especially the key sharing leaves a lot to be desired but for personal use I like it. And I love that there's lots of hardware key support. This is why I use it.

I personally use my hardware OpenPGP keys also for SSH, on yubikeys and OpenPGP smartcards. I also use those for encrypting and signing data. So I'm already doing something similar to start you're saying, just the other way around.

Having my keys on a hardware token is a must-have for me and I wonder if that's possible with your method. I also prefer having a token that requires a hardware input for each use like the Yubikeys can. You can set them up to require a touch for every signature or authentication. This stops a compromised server you log in to from milking your SSH agent.

But how would I store the keys in hardware if not PGP? I tried PKCS11 modules with different cards before but the software chain with middleware is pretty terrible. PGP's is pretty sane (gpg --card-edit is much more user friendly than what was offered by the other more expensive cards I used!)

And I don't like Fido2 either for this because it can't be used for content encryption/signing (which is what your blog post about)

So, I'm pretty open to doing what you're doing but my requirement for hardware key storage makes it pretty hard I think.

It would be nice to hear your thoughts on this, how this could work with hardware-backed keys.

I think you are referring to my comparison of age vs gpg[1]. That in no way indicates that I have anything against authenticated encryption. I just point out that age has no data recovery utility.

BTW, when used in a normal way, an offline capable, stateless system as embodied in the OpenPGP message standard uses signatures to provide integrity protection[2]. Which might bring us a bit closer to the matter at hand I suppose.

[1] https://articles.59.ca/doku.php?id=pgpfan:agevspgp

[2] https://articles.59.ca/doku.php?id=pgpfan:authenticated

Ditto on the hardware token. This SSH signing thing looks to require an actual file in the file system, which is a complete non-starter to those of us who don't keep our keys in ~/.ssh/id_* files.

From the man page:

> The key used for signing is specified using the -f option and may refer to either a private key, or a public key with the private half available via ssh-agent(1).

This whole thread is off-topic (talking about AEAD in a post about signing), but:

You can use age's AEAD encryption with Yubikeys. Yubikeys can do ECDHE in PIV mode.

I wrote https://github.com/tv42/yubage as a subprocess plugin to https://github.com/str4d/rage (and hopefully https://github.com/FiloSottile/age once they think plugins are stable in enough to go in the reference implementation). The rage author also wrote their https://github.com/str4d/age-plugin-yubikey