Comment by schoen | Hacker News Reader

Comment by schoen | Hacker News Reader

Parent Full thread

There might be other reasons not to want these public keys to be published. For example, suppose there is an anonymous developer on a controversial project (maybe one that litigious companies don't want to exist?) who has chosen to have two GitHub accounts, one with the developer's legal name and one with a pseudonym.

If the developer is using the same key with both accounts, GitHub knows about the connection between them, but the larger public doesn't -- until the keys are published.

Another possible source of risk that would relate more to publishing the comment fields (which GitHub apparently chose not to do) is letting an attacker know which client devices to try to steal or compromise in order to get access to a developer's account. (Not a cryptographic attack at all!) It might still be possible to make some guesses about this if you know, for instance, that a developer bought a new laptop in a given week and then added a new key and either did or did not deactivate the old one.

Public keys that are used for confidential communications from the public or for signing publicly-released data probably ought to be distributed widely. But public keys that are used to authenticate to a service also reveal nonpublic facts about the number and activation and deactivation of devices that are used to access that service. If someone is crawling these records and noticing the timing of changes, it may help for planning attacks -- again, noncryptographic ones.

GitHub actually won't let you use the same pubkey in two places, but I get what you're trying to say.

I'll reiterate - you should assume your public key (and any comment on your public key) is already public information, even if GitHub hasn't published your pub key. Anything else is not good security practice.

As far as I can tell, this is not a concern to anyone in crypto -- revealing public keys, that is. Obviously if you're a crypto expert reading this and disagreeing, feel free to chime in, but as far as I know, there are zero concrete crypto reasons to obfuscate a public key.

It's your fault if you put private information in a public key's comment field.

Let me quote from "PGP & GPG -- EMAIL FOR THE PRACTICAL PARANOID":

You can send someone else’s public key to an old-style keyserver. Although you might think this would be a favor, it’s actually extremely rude. The public key owner might have reasons for not using a keyserver and might prefer to distribute his public key via some other method—or he might not want to publicize the key at all beyond a small group of people.

Never publicize someone else’s key for them!

Now, if your reply reiterates your argument that public keys are public because it's in the name, duh, then I can't help..

It's about building a comprehensive security model -- the author of what you quoted would be wrong if he suggests public keys should be considered, at any time, by anyone, to be anything less than public.

Any security model that relies on a public key not being known is a bad security model.

How "rude" an activity is only matters when you're dealing with people who care if you think they're being "rude", and in PKI that's not possible because your public key must be given to untrusted parties.

What's more relevant is the attack surface you present by exposing your public key. Since your security model already assumes they have it through other means, you've given your attacker no new information.

Hiding your public key is textbook "security through obscurity".

Edit: I tweeted the author of the quote you gave (Michael W. Lucas, @mwlauthor) about the above article, I'll try and get him to chime in on our discussion if I can.

What's more relevant is the attack surface you present by exposing your public key. Since your security model already assumes they have it through other means, you've given your attacker no new information.

Unless you're assuming they don't have it via other means. If I have a keypair I only use for GitHub, and GitHub didn't publish pubkeys as they do, then it is a fairly safe assumption that an attacker does not have my public key. Not something to build an entire cryptosystem around, but still a fairly safe assumption.

But I do agree when you say, "Any security model that relies on a public key not being known is a bad security model". It's the difference between "rely" and "this (weak) assumption contributes positively to overall security".

Let's look at a scenario. Say I:

1. use a particular keypair just for GitHub, and nothing else.

2. had generated this key on Debian during the period when it was brokenly generating easily-factorable keys with low entropy.

If GitHub did not publish public keys, then I could then reasonably expect that I was safe for the life of that key. Yes, upon finding out about the vulnerability, I'd immediately revoke and generate a new key, but there were people who unknowingly had vulnerable keys up there for a very long time, and they could have been compromised for a long time, without their knowledge.

Again, no, you can't rely on the public key being private, but publishing it can have some bad side-effects when something unforeseen comes up, and not publishing it can offer you some greater protection than publishing it, even if it's a small amount.

Having said that, I actually don't disagree with GitHub's decision to publish public keys as they do. So: shrug.

> Unless you're assuming they don't have it via other means.

Never, ever assume this of your public key.

The solution to the Debian bug is to use a keypair not generated by the bugged Debian build, not "continue to use the bugged keypair".

Never, ever assume this of your public key.

Why? I mean, I'm not saying it's an absolute 100% certain assumption that any particular public key is secret. I'm saying it's a reasonable assumption that will likely be correct in many cases. Not something to base your faith of a cryptosystem on, of course, but it's a reasonable assumption in many circumstances that can have a positive impact on the actual security of your accounts. The public key I use for my own machines is very unlikely to be known by anyone else, because it's only used on machines I have full and sole control over. Sure, that's not absolute proof (maybe one of my servers has been compromised and I don't know about it), but it's a reasonable assumption.

The solution to the Debian bug is to use a keypair not generated by the bugged Debian build, not "continue to use the bugged keypair".

Duh. If you actually read what I wrote, you'd see I agree with that. I'm talking about the fact that people were using broken keypairs for long time, and didn't know, because the vulnerability hadn't been found and disclosed yet. You won't generate a new keypair if you don't know there's something wrong with the one you have.

My point is that if an attacker knew about the vulnerability a long time before it was fixed and publicly disclosed, GitHub publishing public keys gives that attacker a nice corpus of keys they can check to see if they're vulnerable, and can make use of that information (since the attacker knows that any bad key is known to be used for a particular GH account).

If GH did not publish public keys, all users would have been safe from that particular attack vector. Sure, there are other avenues where an attacker could get ahold of some of those same public keys, but it's probably a vanishingly small percentage of them.

If GitHub did not publish public keys, then I could then reasonably expect that I was safe for the life of that key.

I don't think so, because of the way GitHub's SSH access works - you don't need to know the account associated with a given key to try and authenticate with that key, so trying all 32k "Debian keys" of each size and seeing which ones let you in is quite feasible.

Very good point, though I'd assume that GitHub has rate-limits in place that would catch people trying to brute-force accounts. Still, though, even with that, you're right that your safety margin drops a bit.

I agree with you on the cryptographic point: you shouldn't (have to) expect to get cryptographic security from the secrecy of a public key, regardless of how the public key is used. My point is that there could be other reasons not to publish it, even though it's not a source of cryptographic vulnerability.

It seems to me that in crypto there are plenty of fields where the protocol designer would say "this value is nonconfidential" or "this value is not required to be kept secret" -- reasoning from the protocol's internal cryptographic security goals -- where publishing the value still has other adverse consequences. For instance, TLS session tickets per RFC 5077: "since the ticket is encrypted and the attacker does not know the secret key, a stolen ticket does not help an attacker resume a session".

But the protocol's internal security goals aren't always the only relevant security goals, and in the session tickets example, there is also a privacy sensitivity about disclosing them in some contexts because they can be used to show that a particular party was responsible for a particular TLS sessions (like if you were using Tor to access a web site but then posted the session tickets under your own name because RFC 5077 says that they don't need to be kept secret).

I think that's precisely what's happened here. If you read SSH protocol specs, they will say that public keys never need to be kept secret -- from the point of the SSH protocol's security goals. That's great, and it's a fair point. Users can still have other perfectly reasonable security reasons to request that people not publish them in particular circumstances!

> Users can still have other perfectly reasonable security reasons to request that people not publish them in particular circumstances!

I feel your argument relies on these actually existing -- so what are these reasons?

> Users can still have other perfectly reasonable security reasons to request that people not publish them in particular circumstances!

Yes, but nobody has shown any compelling reasons in relation to pubkeys used for github.

And even if there were some potential small benefit it would have also be weighted against the benefit of having the whole population of pubkeys available for security research.

The OP article clearly exposes problematic practices that might have otherwise gone unnoticed.

> If the developer is using the same key with both accounts

They shouldn't be doing that, though. Each public key should be tied to one identity. (You might have many keys to one identity, but not vice versa.)

GitHub also won't allow you to do that.

Reply on news.ycombinator.com