Hacker News Reader

Comment by fensipens | Hacker News Reader

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..

View on HN

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.

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.

Reply on news.ycombinator.com