Most active commenters

    ←back to thread

    Sign arbitrary data with your SSH keys

    (www.agwa.name)
    637 points h1x | 12 comments | 13 Nov 21 09:13 UTC | HN request time: 0.786s | source | bottom
    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 #
    1. 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 #
    2. 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 #
    3. 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 #
    4. lrem ◴[13 Nov 21 10:48 UTC] No.29208913[source]▶
    Distributing small chunks of text sounds like the wrong problem to call "hard". It is building trust in them. Problems with the web of trust are well documented and pretty much boil down to "random people in the Internet turn out to not really be the most trustworthy of mediums".
    replies(1): >>29209098 #
    5. bawolff ◴[13 Nov 21 11:05 UTC] No.29208975{3}[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 #
    6. Too ◴[13 Nov 21 11:35 UTC] No.29209098{3}[source]▶
    There’s one final problem even harder than that. Creating a UI that by itself explains this whole complex concept, to a user with an average attention span of 3 microseconds.

    Just look at how many scam attacks have been made possible just on urls.

    7. _wldu ◴[13 Nov 21 14:53 UTC] No.29210136[source]▶
    Distribute your public keys via DNS TXT records:

    https://www.go350.com/posts/age-file-encryption/#age-pki-iss...

    replies(1): >>29210519 #
    8. judge2020 ◴[13 Nov 21 15:41 UTC] No.29210519[source]▶
    That only creates a link between SSH keys and a domain; It's even worse than relying on GitHub since you have to trust that multiple account haven't been hacked (registrar + DNS) and that neither the DNS host nor the registrar are acting maliciously.
    replies(2): >>29211385 #>>29212710 #
    9. _hyn3 ◴[13 Nov 21 17:16 UTC] No.29211385{3}[source]▶
    I agree. DNS is its own bundle of insecurity.
    10. CameronNemo ◴[13 Nov 21 20:01 UTC] No.29212710{3}[source]▶
    Psst. Github has all that stuff too. Just more because it is a growing and changing webapp instead of an ancient, solidified key value store.
    11. Spooky23 ◴[14 Nov 21 04:26 UTC] No.29215348{4}[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 #
    12. bawolff ◴[15 Nov 21 10:25 UTC] No.29225790{5}[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.