7 ms·

But the keys are public...

by c22 11y ago

Dylan16807 11y ago
So is the writing on a postcard; doesn't mean you want it published.
Tharkun 11y ago
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.
- dkrich 11y ago
  Or at least give each user the option and default it to unshared. I don't see why they'd default to sharing everyone's.
- the8472 11y ago
  > 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. Sunlight is the best disinfectant.
  - c22 11y ago
    Exactly. 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.
    - fensipens 11y ago
      This is about being able to connect keys to individuals and then searching The Stash for more links that then build a graph. But it's just metadata, isn't it..
      - the8472 11y ago
        If you use a key exclusively for github servers then there's no graph-building. something like the following in ~/.ssh/config Host *.github.com IdentitiesOnly yes IdentityFile ~/.ssh/hostboundkeys/github_ed25519
        kardos 11y ago
        This is the answer right here. Also it's wise to use different keys for different services, for the same reasons that you'd use different passwords.
        robryk 11y ago
        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?
        kardos 11y ago
        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.
- jjuhl 11y ago
  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.
  - mc808 11y ago
    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...
- dimino 11y ago
  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".
  - schoen 11y ago
    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.
    - dragonwriter 11y ago
      > 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.)
      - 11y ago

But the keys are public...

by c22 11y ago

But the keys are public...

Dylan16807 11y ago

So is the writing on a postcard; doesn't mean you want it published.

Tharkun 11y ago

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.

dkrich 11y ago
Or at least give each user the option and default it to unshared. I don't see why they'd default to sharing everyone's.
the8472 11y ago
> 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. Sunlight is the best disinfectant.
- c22 11y ago
  Exactly. 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.
  - fensipens 11y ago
    This is about being able to connect keys to individuals and then searching The Stash for more links that then build a graph. But it's just metadata, isn't it..
    - the8472 11y ago
      If you use a key exclusively for github servers then there's no graph-building. something like the following in ~/.ssh/config Host *.github.com IdentitiesOnly yes IdentityFile ~/.ssh/hostboundkeys/github_ed25519
      - kardos 11y ago
        This is the answer right here. Also it's wise to use different keys for different services, for the same reasons that you'd use different passwords.
        robryk 11y ago
        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?
        kardos 11y ago
        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.
jjuhl 11y ago
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.
- mc808 11y ago
  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...
dimino 11y ago
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".
- schoen 11y ago
  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.
  - dragonwriter 11y ago
    > 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.)
    - 11y ago