10 ms·

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 leak

by Tharkun 11y ago

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

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?
  - 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
fensipens 11y ago
I agree, this is rude and as far as I remember, it's not mentioned anywhere in the key upload interface. It's equivalent to uploading someones PGP key to a keyserver without his or her permission.
uxcn 11y ago
I hoped my key wasn't effectively public by using it with github, but I honestly tend to assume the worst whenever I use a service like it.
baby 11y ago
> from the public keys they publish without permission Public Keys are supposed to be public. It's OK not to know that, but blaming Github for doing crypto right is not really clever... If you don't want your public key to be traced back to you, generate a new pair just for github.
- fensipens 11y ago
  blaming Github for doing crypto right So github is doing crypto right by unnecessarily exposing data that is _only_ relevant to a) the user and b) his personal access to his repos? By this logic, why not make crypto even better and add something like github.com/user.address, github.com/user.mail or github.com/user.phone?
  - the8472 11y ago
    your analogy is very flawed. 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
    - uxcn 11y ago
      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. [1] https://news.ycombinator.com/item?id=9648351 https://news.ycombinator.com/item?id=9648351

by Tharkun 11y ago

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

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

fensipens 11y ago

I agree, this is rude and as far as I remember, it's not mentioned anywhere in the key upload interface. It's equivalent to uploading someones PGP key to a keyserver without his or her permission.

uxcn 11y ago

I hoped my key wasn't effectively public by using it with github, but I honestly tend to assume the worst whenever I use a service like it.

baby 11y ago

> from the public keys they publish without permission Public Keys are supposed to be public. It's OK not to know that, but blaming Github for doing crypto right is not really clever... If you don't want your public key to be traced back to you, generate a new pair just for github.

fensipens 11y ago
blaming Github for doing crypto right So github is doing crypto right by unnecessarily exposing data that is _only_ relevant to a) the user and b) his personal access to his repos? By this logic, why not make crypto even better and add something like github.com/user.address, github.com/user.mail or github.com/user.phone?
- the8472 11y ago
  your analogy is very flawed. 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
  - uxcn 11y ago
    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. [1] https://news.ycombinator.com/item?id=9648351 https://news.ycombinator.com/item?id=9648351