←back to thread

Sign arbitrary data with your SSH keys

(www.agwa.name)
637 points h1x | 3 comments | 13 Nov 21 09:13 UTC | HN request time: 0.002s | source
Show context
dane-pgp ◴[13 Nov 21 09:55 UTC] No.29208701[source]▶
> 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-...

replies(2): >>29208803 #>>29208944 #
IYasha ◴[13 Nov 21 10:20 UTC] No.29208803[source]▶
Thanks for the insight and links!

And really... > relying on a trusted third party ... like GitHub seems like a way better default than PGP's Web of Trust

Made me scream: "What??" I'd personally prefer some decentralized torrent-like way of user key distribution.

replies(2): >>29208819 #>>29210136 #
majou ◴[13 Nov 21 10:24 UTC] No.29208819[source]▶
What would that look like? Distributing keys is always the hard part.
replies(2): >>29208904 #>>29208913 #
IYasha ◴[13 Nov 21 10:46 UTC] No.29208904[source]▶
Well, I tried to avoid saying blockchain, which is already being implemented https://hackernoon.com/decentralized-public-key-infrastructu... but is resource-heavy. On the second thought, there are potential problems with DHT-like way of distribution (rogue peer overwhelming, etc) I can't seem to find article on this idea (it's pretty old), sorry.
replies(1): >>29208975 #
1. bawolff ◴[13 Nov 21 11:05 UTC] No.29208975[source]▶
Its kind of missing the point (unless im missing something). The hard part is linking keys to well known identifiers (ensuring that a malicious person can't trick you into thinking you have someone else's key when you really have the evil person's).

Having an append-only store is not the hard part of the problem and there are much better solutions than blockchains for that.

replies(1): >>29215348 #
2. Spooky23 ◴[14 Nov 21 04:26 UTC] No.29215348[source]▶
Identifiers are just attributes. If you want to attach a library card, US Passport, refugee id to a blockchain instance of your identity, you can inherit that endorsement.

In NIST speak, you can get a level 2 assurance level (good for most commerce) by collecting two strong identifiers or verifying one.

replies(1): >>29225790 #
3. bawolff ◴[15 Nov 21 10:25 UTC] No.29225790[source]▶
That does not solve the problem. If it did, we would have solved the problem decades ago

Case in point - pgp supports exactly that - you can have keys, which can have attributes which are endorsed by your key. We've had this since the 90's. It didn't solve the problem back then, reinventing the same thing but worse using blockchains won't solve the problem now.