[schoen]

I was kind of disturbed that GitHub publishes every user's public key.

https://developer.github.com/v3/users/keys/

This is a different situation and public keys are not directly analogous to password hashes: there isn't a reliable way of cracking public keys in the same sense that there's a semi-reliable way of cracking hashes. But it was still strange and uncomfortable to me that they would reveal this "target" (and if there were specific key generation bugs, like RNG seeding errors, people might actually be able to crack a few of them and know that they had suceeded).

Relatedly, I was thinking about the magic crypto-cracking device in the movie Sneakers. Once they had it, they could immediately use it to log on to random network-connected services, defeating the authentication. So, how is that supposed to work? How do they automatically know what credentials would be accepted for a particular service? Are there common network authentication protocols based on public-key cryptography that have the property that the verifier tells the prover the public keys that it trusts?

[LinuxBender]

You can have a GitHub specific ssh key.

  ssh-keygen -q -t rsa -b 4096 -N "passphrase" -C "[e-mail]" -f ${HOME}/.ssh/.ghub

then in your ${HOME}/.ssh/config

  IdentitiesOnly yes
  Host github.com
    Hostname ssh.github.com
    Port 443
    User git
    IdentityFile /home/username/.ssh/.ghub
    ForwardAgent no

Not that it matters in this case, just sayin'.

[BenjiWiebe]

In fact, I have a machine specific GitHub specific key.

[irundebian]

2048 is enough.

[snakeanus]

For now. https://www.keylength.com/en/compare/

Why risk it when generating an ed25519 or rsa4096 keypair is cheap?

[irundebian]

The same logic would apply to an 8192 bit key. One more bit doubles the key space. Someone who is be able to crack 2048 bit keys, probably also has the opportunity to crack 4096 bit keys. It may not be cheap for your communication partners to use your 4096 bit key. Smartphones and embedded devices want to use as less energy as possible. With an 4096 bit key, you force your communication partners to spent an unnecessary amount of energy.

[snakeanus]

> One more bit doubles the key space

Yes, except that a 4096 bit key is not just "one more bit", it's double the amount of bits.

> Someone who is be able to crack 2048 bit keys, probably also has the opportunity to crack 4096 bit keys

No, it would require an impossibly large amount of effort to crack 4096 bit keys compared to 2048 bit keys.

> Smartphones and embedded devices want to use as less energy as possible

They can use ed25519 then.

> With an 4096 bit key, you force your communication partners to spent an unnecessary amount of energy.

They spend more energy by running ad-ridden "apps" and electron monstrosities.

[LinuxBender]

I agree. I used 4096 in the example just in case my great grandkids find this post. They will have Quantum implants.

[problems]

I wouldn't really say this is significant in an attack sense - you need to reveal your public key to engage in many types of secure communication, SSL throws these around all day as does any private messaging app, PGP, SSH servers, etc. The entire point of a public key is that it is public, password material on the other hand is not, it's meant to be a shared key between you and the other party.

The only bad thing about the GitHub issue there is that a de-anonymization attack is possible as an SSH server will tell you if it accepts a given public key... if, say you had the same SSH key on your GitHub account and a server you wanted to keep private, this could be bad to say the least. And SSH clients offer every id_* key to every server they connect to, so if you connect to an untrustworthy server, even over an anonymity network like Tor your client may offer a key that identifies you (use your ssh config!).

[etaty]

If I remember, SSH server don't share the public key it accepts. Your SSH agent will try all your key one by one (you can change this behaviour with custom config)

[problems]

Yes, but similarly if you have a given public key you can ask a server if it accepts that key with no need for the private key.

Basically, don't reuse keys in places where you might not want to be identified and use ssh configs to prevent announcing all keys to the world.

[bogomipz]

?"The only bad thing about the GitHub issue there is that a de-anonymization attack is possible as an SSH server will tell you if it accepts a given public key"

Could you elaborate more on this specific attack?

[problems]

A quick overview of how SSH key authentication works:

> SSH client: I support key auth

> SSH server: Let's use key auth

> SSH client: Do you take this public key hash: XXXXXX?

> SSH server: Yes I do

or

> SSH server: No I don't

Repeat for as many keys as you like.

You can therefore grab a list of known public keys for a given person and ask a given ssh server if it knows about the given public key. Given a few days you could even scan the entire IPv4 space for servers taking a given public key. Username must match, etc of course, but it's an attack many people might not consider.

[bdamm]

Expanding this to the tor case that the GGP outlined, even if the server isn't compromised the use of the same key in two very different contexts (for git and for your silkroad command console) reveals that the client is one and the same. I believe just packet sniffing can ascertain this.

[bogomipz]

Sure, you would still need a Linux userid on that host (I'm assuming that PermitRootLogin is set to No.) Although that's probably easy to guess considering a person's name is often available in from Github or even the default comment field that ssh-keygen adds.

[dsacco]

I'm confused, why would you be disturbed that GitHub publishes every user's public key? This is quite literally the design intention of public keys.

[scintill76]

I disagree. The design intention of public keys is not that they should be published along with a mapping to the user's identity, without the user's consent. It's that they may be published, or eavesdropped, without breaking the cryptography itself. See here[0] for the privacy-violating consequences of publishing public keys and identities wholesale.

[0] https://news.ycombinator.com/item?id=10004678

[dsacco]

That's not a failure of public key cryptography, that's a failure of the SSH protocol.

As you say, public keys were designed to solve a key distribution problem. Inherent to that problem is the idea that a public key could become, well, public. They solve that problem very well, and there is no intrinsic reason why you shouldn't just publish them because they were intended to be defensible against that very eventuality.

Practically speaking I disagree that GitHub has done anything wrong here - changing habits to diminish the publish-ability of public keys because the SSH protocol exhibits suboptimal behavior encourages further lazy security for the SSH protocol.

We shouldn't tap dance around an SSH-specific problem by claiming that public keys need to be kept secret. That's absurd, we already have private keys. Moreover, it is detrimental to other protocols that rely on publicly verifiable signatures and nonrepudiation to adopt this sort of perspective.

[scintill76]

> That's not a failure of public key cryptography, that's a failure of the SSH protocol.

But Github is using public key cryptography as implemented in SSH - if that has a failure, Github should take some blame for not working around it, especially when they are going out of their way to expose data that has little benefit IMO.

Anyway, SSH is orthogonal to one of my points, which, phrased another way, is that publishing the link between two identities (the key itself, and the key-owner's Github profile) without consent or need is unethical because it violates the privacy of the owner. I believe there is precedent in the PGP world (e.g., "I believe it's poor etiquette to upload someone else's key to a keyserver as you deny them that choice."[0])

I sort of get the "detrimental to other protocols" and "lazy security for the SSH protocol" points, but when you talk about publishing public keys, do you acknowledge a difference between "key XYZ is in use on Github" and "key XYZ identifies user ABC on Github"? I'm saying the latter is unwise and unkind, and it would be even if the SSH protocol didn't have this particular failure.

[0] https://stackoverflow.com/a/27254303

[jwilk]

If you prefer plain-text format, this is available at:

  https://github.com/<user>.keys

[avaika]

Well, but these are the public keys. All you can is just to install it to your system and wait for someone to login using the private part... A lot of people would like to see the working way to get the private key out of public key :)