At least Github were "kind" enough to strip the comments from the public keys they publish without permission. I would've been even more upset if they were leaking things like username@workdomain....
public keys are essentially opaque tokens that do nothing more than ensuring that a counterpart of a connection is whoever you think is associated with the public key. The key itself does not convey that information. It conveys no information at all beyond its cryptographic properties.
Turning a key into anything else (e.g. through re-use, publishing it elsewhere in association with other data) is not an intrinsic property of the key.
On the other hand personal data such as an address cannot be easily replaced like a key, immediately ties it to a person and does not provide any cryptographic properties at all.
TL;DR: pubkey is not private data, user.address is not crypto
The analogy isn't flawed, it's a question of the benefit for the person who's key/info it is, in this case github users. We generally don't have anything to gain from our keys being made public (address, phone number, etc...). It's also a generally accepted faux pas to share someone else's public key for them. Quoted from another comment[1] (quoted from 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!
Admittedly, it's a risk we should be aware of. But regardless of whether it's rude or not, it doesn't seem to be what people expect. What's worse though is that whether it's malicious or not; user trust is practically impossible to get back after it's gone.
That's my point. They shouldn't be. I never gave Github permission to publish my keys. The "public" part in the key is merely there to distinguish it from the "private"-part ("never share this with anyone"). It should signify "share this with people whose machine you want to access", not "share this with the whole world".
From a healthy paranoid point of view: you don't share your public key unless you have to. Sure, there are no known attacks on strong RSA keys today, but that doesn't mean there will never be. Why take that risk with, literally, thousands of keys and people's security? It's rude at the very least.
Of course, you should never use your Github keys for anything else, but that's beside the point entirely.
As for the comments: key comments are useful but often contain information that can identify a person (e-mail address, username@machine etc). Publishing that would have been even worse.
> Why take that risk with, literally, thousands of keys and people's security?
I would say it encourages scrutiny. The assumption of public keys is that they are public, if any part of your security architecture relies on a public key being private then it would seem flawed, flaws that should be exposed.
And if them being public induces extra paranoia, such as using separate keys only for github then all the better.
These keys are not less secure for being published, but moreso. At least now the public can determine whether or not we trust these keys and any edits made with them as opposed to weaknesses in their security going abused without notice.
# IdentityFile magic, should be placed at very end of file
Host *
IdentityFile ~/.ssh/keys/id_ecdsa_%r@%h
IdentityFile ~/.ssh/keys/id_rsa_%r@%h
IdentityFile ~/.ssh/keys/id_ecdsa_ANY@%h
IdentityFile ~/.ssh/keys/id_rsa_ANY@%h
IdentityFile ~/.ssh/keys/id_ecdsa_%r@ANY
IdentityFile ~/.ssh/keys/id_rsa_%r@ANY
IdentityFile ~/.ssh/keys/id_ecdsa_ANY@ANY
IdentityFile ~/.ssh/keys/id_rsa_ANY@ANY
Will look for user@host, ANY@host, user@ANY, then ANY@ANY keys. You can add ed25519 to this.
This looks pretty neat -- however, do you use passphrases for your keys, and if so, how do you manage them? Only 2 obvious solutions spring immediately to mind - use the same (or none) pass for each key, or have a unique one per-key and some sort of separate password database with a master password.
At least, I can't imagine memorising enough unique passphrases for all the user/host combinations I currently have.
I'm hoping there's some clever built-in or easily added (like keychain/agent) way to secure individual keys on the filesystem without excess complexity when using them.
The IdentifyFile directives actually work with ssh-agent - it will try the keys listed there first, using them via the agent if they're loaded. I use the same passphrase on all keys and load them into my agent all at once (when loading, the last passphrase you entered will be tried to decrypt each key).
Normally, the problem with having many keys in the agent is that a server you're logging into will boot you after supplying too many keys it doesn't accept, but this fixes that.
When I share a password between two services, they get the plaintext password when I authenticate, so the first one can impersonate me in front of the second one. How does this apply to keys?
If you have one key, and use it for N services, compromising your key compromises N accounts. If you use one key per service, compromising a key only compromises one account.
If you have your N private keys all stored on the same device (such as side-by-side in your ~/.ssh/keys directory, as in ryan-c's example upthread), under what scenario would just one of those keys get compromised?
You only need one private key per device to be secure. The benefit of using separate keys per service is privacy - it prevents the various service providers from colluding to determine that you're a user of all the services (but if you're not careful you're probably leaking other information to them that would let them learn this anyways).
If you're not using passphrases on your keys, then yes they are locally wide open, much like a passwords.txt strategy for passwords. If you do passphrase them, the attacker now needs N passphrases. Perhaps you notice the keylogger before all passphrases get logged? There are probably more scenarios where N keys is strictly better than one, but that's the first that comes to mind.
I agree with the privacy aspect, it's that's the same point that the8472 made.
"perhaps you don't use password manager and you notice the keylogger halfway through" is a pretty unlikely scenario to motivate me to use a bunch of unique passphrases.
It's not "strictly better" when it hurts your ability to use and memorize strong passes.
> if any part of your security architecture relies on a public key being private then it would seem flawed
What about your privacy architecture? Can the public key be derived from a packet capture of SSH? My quick session with Wireshark and layman's protocol/crypto understanding says probably not. But it seems possible that while the crypto may be designed such that the public key may be public without endangering the cryptography, there are still privacy reasons (being able to identify people by unique public key) to not share it any more widely than it needs to be.
For example, it seems like I have read that PGP public keys can be read in the clear, which allows metadata graphs to be built by passive interceptors. Maybe SSH doesn't have that issue though.
AIUI A SSH session first performs a DH key exchange and authenticates the server. Only over that already-encrypted session will the client offer its public keys.
That means the public key will not be leaked to outside observers. Combine with server-specific keys to avoid potential "try logging into my server" social engineering.
This means only the server will ever learn your public key, but it has to know that already anyway.
So publishing your public key does not leak any privacy bits.
I think that packet is encrypted, though -- at least, it looks like that in Wireshark to me. I see key exchange packets and the following ones seem to become encrypted, before I have given ssh-agent the approval to use my key. I am mostly going off of what Wireshark's protocol decoders tell me, though, so I could be wrong.
Assuming for a moment that this problem exists: That wouldn't change anything about my argument. If privacy is part of the threat model then privacy shouldn't be conditional on the public key being kept secret.
By publishing the key you expose the flaw in that setup.
FWIW I'm surprised you got downvoted, and it wasn't me. Is privacy part of the threat model? The closest thing I could find is http://iacr.org/archive/asiacrypt2001/22480568.pdf , "Key-Privacy in Public-Key Encryption" (2001), where they conclude most RSA encryption schemes are not anonymous.
If that applies to SSH, I see no problem in asking for "public key secrecy" as a requirement/option in a layer above the crypto.
I'm sorry, but you misunderstand what a public key is if you merely think of "public" as a way to distinguish between private.
If your security model relies on public keys not being publicly known, then your security model can't reasonably be expected to work or be honored by GitHub.
Considering a public key as a "shared secret", as you're claiming it is, moves beyond "healthy paranoid" and into just "paranoid".
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.
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!
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.
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.
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.
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 the crypto you use is sound/strong there is no reason-not-to/risk in making the public key known to everyone and his dog. If the crypto is not sound then the solution is not to hide the public key (security by obscurity style), it is to use better crypto.
If the crypto/implementation turns out to be unsound, first you have to 1. learn that the flaw exists, and then 2. take steps to remedy the situation. That's a window of opportunity where "obscurity" can potentially buy you time. On the other hand, if you assume your public keys are widely known and distributed, you're more likely to drop everything and take care of step 2 ASAP. So maybe it's a wash...
