3 ms·

Well, maybe when some of these keys were made, they were sufficiently complex, but now they're not. Revealing those public keys has potentially given attackers

Well, maybe when some of these keys were made, they were sufficiently complex, but now they're not. Revealing those public keys has potentially given attackers months/years to try to factor them offline. If the public keys were not known, Github would have a chance (and hopefully does) of rate-limiting brute-force attacks. Heck, even if Github is doing nothing to help against brute-forcing, just hiding public keys might make the bandwidth costs more infeasible than the cost of factoring a known public key.

dimino 11y ago
They're insecure whether or not GitHub makes them viewable. All you get by not publishing your public key is a false sense of security. This is textbook security through obscurity, and is considered ill-advised by the security community.
- scintill76 11y ago
  But in real-world terms, some users are less likely to be compromised if GitHub hadn't published them. In that light, I don't think it's advisable for GitHub to go out of their way to publish them without the user's knowledge. I think the "security through obscurity" principle ought to, if it doesn't already include this, say that added measures or core design principles should not be based on obscurity. This should not mean that all obscurity must be removed. In this case, GitHub have added anti-obscurity, and the defense is mainly dogmatic mis-application of the principle IMO.
  - baby 11y ago
    if they are "compromised" then the whole security of internet is.
    - scintill76 11y ago
      Oh, the whole internet is using 512-bit RSA keys, like some GitHub users were? (And I did say "some" before, not "all" or "whole internet".) My point is that the 512-bit users would not have been targetable if nobody knew their keys were 512 bits long. And with bandwidth constraints, their keys would probably not have been bruteforceable either. Due to GitHub publishing their keys, they were targetable, potentially for months, plenty of time to factor. I guess the response to that will be something about how they don't "deserve" protection because they used weak keys, and while I would resent that sentiment, I can't really argue against the idea. To sum up, GitHub is doing something cryptographically unnecessary for this use case, that potentially harms confidentiality and anonymity for some users, and the arguments in favor seem to be: 1) A few users find it marginally useful, 2) It doesn't break the actual crypto if the users do it right, 3) Obscurity is taboo, 4) The name is "public key". I'll grant my position is weak, but so are those arguments. Their primary strength is dogma. Which, I don't know, maybe drilling crypto basics does have a net benefit even if they're not applicable to every situation.
      - baby 11y ago
        > My point is that the 512-bit users would not have been targetable if nobody knew their keys were 512 bits long This is wishful thinking. A Man In The Middle Attack would have worked on him.
        scintill76 11y ago
        MITM SSH to get the public key and factor it? My understanding from other discussions in this thread is that the publickey authentication protocol is encrypted with the server's host key. Are you relying on the user ignoring key mismatch errors, or targeting them on the first connection and relying on them not checking the key fingerprint? Or something else entirely? I'd like to learn if there's something I haven't thought about here.
  - dimino 11y ago
    > But in real-world terms, some users are less likely to be compromised if GitHub hadn't published them. This is not true.
    - scintill76 11y ago
      Can you read my reply to your "sibling" comment, especially regarding 512-bit keys? I want to know if I have a factual misunderstanding. Or maybe we disagree on probability or something.
      - dimino 11y ago
        The solution to "my key is easily factorable" is not "hide the key", it's "get a new key". Factually you haven't said anything I know to be wrong.
        scintill76 11y ago
        I agree, with the (silly?) distinction that it's not "hiding" like a secret key, it's just "not showing to the whole world" because they never had a good reason in the first place IMO. Had they not published them, it would address the privacy concerns some of us have, and happen to band-aid over the easily factorable keys too. I guess I'll agree that's not really a legitimate reason to make them "hide" them now... it's mainly my preference for avoiding metadata leakage. I shouldn't have focused so much on factoring. Just in case anyone is still reading, some rough analogies: Would you publish intermediate state data from a hashing or signing process? Would you publish your users' password hashes (even w/ scrypt and robust character set+length requirements)? Would you re-use Bitcoin addresses that have spent before?[1] Would you add a feature to an SSH server to return users' public keys to anyone on the internet? Would you have GPG auto-publish new keys to keyservers? I see these as not usually fatal, but not smart or necessary things, somewhat similar to this. [1] One of the justifications for address rotation in Bitcoin is that once the address has spent, its 512-bit ECDSA public key is known, rather than just a RIPEMD160(SHA256()) hash of the public key. Absurd paranoia, lack of understanding crypto, or defense in depth?
baby 11y ago
It's not because you had more time that you will be able to crack a 1024bits RSA public key.
- scintill76 11y ago
  Are you talking about how factoring will take more time than anyone has available, or something?

dimino 11y ago

They're insecure whether or not GitHub makes them viewable. All you get by not publishing your public key is a false sense of security. This is textbook security through obscurity, and is considered ill-advised by the security community.

scintill76 11y ago
But in real-world terms, some users are less likely to be compromised if GitHub hadn't published them. In that light, I don't think it's advisable for GitHub to go out of their way to publish them without the user's knowledge. I think the "security through obscurity" principle ought to, if it doesn't already include this, say that added measures or core design principles should not be based on obscurity. This should not mean that all obscurity must be removed. In this case, GitHub have added anti-obscurity, and the defense is mainly dogmatic mis-application of the principle IMO.
- baby 11y ago
  if they are "compromised" then the whole security of internet is.
  - scintill76 11y ago
    Oh, the whole internet is using 512-bit RSA keys, like some GitHub users were? (And I did say "some" before, not "all" or "whole internet".) My point is that the 512-bit users would not have been targetable if nobody knew their keys were 512 bits long. And with bandwidth constraints, their keys would probably not have been bruteforceable either. Due to GitHub publishing their keys, they were targetable, potentially for months, plenty of time to factor. I guess the response to that will be something about how they don't "deserve" protection because they used weak keys, and while I would resent that sentiment, I can't really argue against the idea. To sum up, GitHub is doing something cryptographically unnecessary for this use case, that potentially harms confidentiality and anonymity for some users, and the arguments in favor seem to be: 1) A few users find it marginally useful, 2) It doesn't break the actual crypto if the users do it right, 3) Obscurity is taboo, 4) The name is "public key". I'll grant my position is weak, but so are those arguments. Their primary strength is dogma. Which, I don't know, maybe drilling crypto basics does have a net benefit even if they're not applicable to every situation.
    - baby 11y ago
      > My point is that the 512-bit users would not have been targetable if nobody knew their keys were 512 bits long This is wishful thinking. A Man In The Middle Attack would have worked on him.
      - scintill76 11y ago
        MITM SSH to get the public key and factor it? My understanding from other discussions in this thread is that the publickey authentication protocol is encrypted with the server's host key. Are you relying on the user ignoring key mismatch errors, or targeting them on the first connection and relying on them not checking the key fingerprint? Or something else entirely? I'd like to learn if there's something I haven't thought about here.
- dimino 11y ago
  > But in real-world terms, some users are less likely to be compromised if GitHub hadn't published them. This is not true.
  - scintill76 11y ago
    Can you read my reply to your "sibling" comment, especially regarding 512-bit keys? I want to know if I have a factual misunderstanding. Or maybe we disagree on probability or something.
    - dimino 11y ago
      The solution to "my key is easily factorable" is not "hide the key", it's "get a new key". Factually you haven't said anything I know to be wrong.
      - scintill76 11y ago
        I agree, with the (silly?) distinction that it's not "hiding" like a secret key, it's just "not showing to the whole world" because they never had a good reason in the first place IMO. Had they not published them, it would address the privacy concerns some of us have, and happen to band-aid over the easily factorable keys too. I guess I'll agree that's not really a legitimate reason to make them "hide" them now... it's mainly my preference for avoiding metadata leakage. I shouldn't have focused so much on factoring. Just in case anyone is still reading, some rough analogies: Would you publish intermediate state data from a hashing or signing process? Would you publish your users' password hashes (even w/ scrypt and robust character set+length requirements)? Would you re-use Bitcoin addresses that have spent before?[1] Would you add a feature to an SSH server to return users' public keys to anyone on the internet? Would you have GPG auto-publish new keys to keyservers? I see these as not usually fatal, but not smart or necessary things, somewhat similar to this. [1] One of the justifications for address rotation in Bitcoin is that once the address has spent, its 512-bit ECDSA public key is known, rather than just a RIPEMD160(SHA256()) hash of the public key. Absurd paranoia, lack of understanding crypto, or defense in depth?

baby 11y ago

It's not because you had more time that you will be able to crack a 1024bits RSA public key.

scintill76 11y ago
Are you talking about how factoring will take more time than anyone has available, or something?