4 ms·

> Specifically because, at least theoretically, it could be used to derive your private key. What theory? I'm unaware of a current working theory that could b

• scintill76 11y ago
  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.
  • 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?