7 ms·

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

by 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.)
  - dimino 11y ago
    GitHub also won't allow you to do that.
- dimino 11y ago
  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.
  - fensipens 11y ago
    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..
    - dimino 11y ago
      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.

by dimino 11y ago

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.)
- dimino 11y ago
  GitHub also won't allow you to do that.
dimino 11y ago
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.
- fensipens 11y ago
  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..
  - dimino 11y ago
    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.