←back to thread

Sign arbitrary data with your SSH keys

(www.agwa.name)
637 points h1x | 4 comments | 13 Nov 21 09:13 UTC | HN request time: 0s | source
Show context
pizza ◴[13 Nov 21 10:03 UTC] No.29208734[source]▶
I get that they're "public" keys, but I was surprised to learn (and from somebody other than github themselves) that ssh public keys are just available at that github.com/username.keys URL (without there being an option to disable it, it seems?). Did most people already know that? Probably fine but just surprised. Just tried searching their authentication docs [0] and I don't get any results for "public key url" either

https://docs.github.com/en/authentication?query=public+key+u...

replies(26): >>29208748 #>>29208752 #>>29208754 #>>29208768 #>>29208790 #>>29208806 #>>29208828 #>>29208856 #>>29208877 #>>29208909 #>>29208990 #>>29209073 #>>29209103 #>>29209113 #>>29209243 #>>29209399 #>>29209634 #>>29210045 #>>29210085 #>>29210460 #>>29211355 #>>29211357 #>>29211783 #>>29212241 #>>29212499 #>>29213083 #
Edmond ◴[13 Nov 21 11:35 UTC] No.29209103[source]▶
>I get that they're "public" keys

From your quote around "public", I presume you think there is some sense in which they're not really public? They are and should ALWAYS be considered PUBLIC. If you find yourself ever crafting a security solution where public keys somehow need to be private or secret, go back to the drawing board or reach out to someone with serious expertise.

There are cases where information on a certificate (which is associated with a public key)may indeed need to be protected, in that case you need to implement an information mask (via hashing) that can protect the private information, we had to do something similar with Certisfy.com certificates. But public keys should be considered public without exceptions.

replies(8): >>29209253 #>>29209264 #>>29209312 #>>29209521 #>>29209535 #>>29210485 #>>29211342 #>>29211702 #
numair ◴[13 Nov 21 12:16 UTC] No.29209253[source]▶
> If you find yourself ever crafting a security solution where public keys somehow need to be private or secret, go back to the drawing board or reach out to someone with serious expertise.

I know you’re taking the “strict teacher” approach with your comment, but you’re totally wrong. And the reason you’re wrong is, security doesn’t equal privacy. But for the “average person,” security does equal privacy, or should, so they find systems that could potentially expose their identity to be “insecure.”

In this particular case, there have been past examples of using keys to fingerprint users without their consent. Yes, it’s been super edge-case and proof-of-concept, but for a lot of people — and perhaps more importantly, in a lot of jurisdictions — leaving a personal identifier sitting around like this (without ever informing the user!) is the very opposite of a best practice.

The end result is, you should only have a key on GitHub that isn’t used anywhere else. That’s what I do, and I’m sure lots of us on this comment thread do, but there’s definitely lots of My First Coding Bootcamp people who were guided through their GitHub account installations who might not have been aware that these are keys that shouldn’t be reused elsewhere.

I would have a very different view on this if GitHub had been explicit about the use of registered keys for other services. That’s a GREAT concept, but I’m not going to trust a company with that business when they’ve just backdoored themselves into it without asking for permission. And the problem for them is, in this particular situation you need the weird paranoid privacy crowd on your side for it to work.

replies(4): >>29209298 #>>29209614 #>>29209616 #>>29210172 #
laumars ◴[13 Nov 21 13:40 UTC] No.29209614[source]▶
If you need privacy then you shouldn’t be uploading to GitHub in the first place. The moment you do that you’re publishing email addresses, other projects that you contribute too and potentially leaking your timezone by virtue of commit times.

Your SSH public key is really the least of your identifiable information you’d be worried about because that’s the easiest to create a unique key for GitHub.

replies(7): >>29209725 #>>29209781 #>>29209999 #>>29210454 #>>29211406 #>>29212355 #>>29212552 #
1. csdvrx ◴[13 Nov 21 19:37 UTC] No.29212552{3}[source]▶
> Your SSH public key is really the least of your identifiable information you’d be worried about

I disagree. The article points to simplifications that SSH did compared to GPG, like no web of trust.

But there's now something very close to one, a bit hidden though: SSHFP + DNSSEC

I think a lot of people here may not be familiar with SSHFP records, so check https://fanf.livejournal.com/130577.html for a more detailed explanation.

It's more or less a work around the problem of initially trusting a key, by using SSHFP records to verify that the server keys are validated by the domain, with DNSSEC validating the whole thing.

When you can match server keys to domains and user keys to github users, you are just one link away from having a global picture of the web of trust.

EDIT: and I wonder how feasible it would be to do just that with a sniff of the initial handshake

> because that’s the easiest to create a unique key for GitHub

And how many people do you think have done that, instead of uploading the keys of the servers/laptops/etc. they use?

I hate to say this, but Bitcoin did it right: by having a discardable private+public pair of keys derived from a seed key, it prevents leaks of information by correlation based on the public key.

replies(2): >>29213584 #>>29213954 #
2. laumars ◴[13 Nov 21 22:04 UTC] No.29213584[source]▶
> And how many people do you think have done that, instead of uploading the keys of the servers/laptops/etc. they use?

Equally they might use the same user name as on other services, thus making them traceable.

Ultimately if you care about privacy then it’s up to you, the individual, not to share that information or to provide anonymous information yourself.

Sharing identifiable information and then blaming the company you shared it with is like blaming the horse for bolting after you’ve intentionally left the barn door open. Sure it should be that way but ultimately it’s your own responsibility to keep your stuff safe.

I’d agree with your point more if you were advocating that documentation should be more explicit. Ie helping educate users into making smarter choices.

3. numair ◴[13 Nov 21 23:07 UTC] No.29213954[source]▶
Thanks for posting this — it’s super-interesting. It seems as though it’s more about authenticating the server rather than the user, unless I read it wrong?

The setup process looks a bit crazy, so I’m hoping it’s gotten easier since 2014? I would love to test it out, but life is too short for the process they’ve outlined...

replies(1): >>29214663 #
4. csdvrx ◴[14 Nov 21 01:08 UTC] No.29214663[source]▶
> It seems as though it’s more about authenticating the server rather than the user, unless I read it wrong?

You are correct.

> The setup process looks a bit crazy, so I’m hoping it’s gotten easier since 2014?

I don't think I used that in uni, so I can't tell you how complicated it was. It's just a nice didactic article that I found explained all the details.

In practice in 2021, you run a sshfp script on the server, and publish the output of the script on your DNS by adding a key.

If you use scripted DNS, it's a one step process, if not, a 2 step process.