8 ms·

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 "

by 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.
        c22 11y ago
        And unlike passwords the extra overhead of maintaining multiple keys is virtually frictionless.
        agwa 11y ago
- scintill76 11y ago
  > 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.
  - the8472 11y ago
    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.
    - scintill76 11y ago
      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 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.
  - drewbug 11y ago
    Actually, it looks like the public key can be derived from a packet capture of SSH. See https://tools.ietf.org/html/rfc4252#section-7 https://tools.ietf.org/html/rfc4252#section-7
    - scintill76 11y ago
      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.
- hinkley 11y ago
  >Sunlight Did your dad ever come into your room and throw open the curtains to get you to get your lazy ass out of bed? Today you know he was probably right, but how did you feel about it when it was happening? Probably not very good.
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

by Tharkun 11y ago

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.
        c22 11y ago
        And unlike passwords the extra overhead of maintaining multiple keys is virtually frictionless.
        agwa 11y ago
scintill76 11y ago
> 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.
- the8472 11y ago
  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.
  - scintill76 11y ago
    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 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.
- drewbug 11y ago
  Actually, it looks like the public key can be derived from a packet capture of SSH. See https://tools.ietf.org/html/rfc4252#section-7 https://tools.ietf.org/html/rfc4252#section-7
  - scintill76 11y ago
    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.
hinkley 11y ago
>Sunlight Did your dad ever come into your room and throw open the curtains to get you to get your lazy ass out of bed? Today you know he was probably right, but how did you feel about it when it was happening? Probably not very good.

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