Hacker News Reader

Comment by the8472 | Hacker News Reader

> 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.

View on HN

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.

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..

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

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.

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?

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.

And unlike passwords the extra overhead of maintaining multiple keys is virtually frictionless.

If you have your N private keys all stored on the same device (such as side-by-side in your ~/.ssh/keys directory, as in ryan-c's example upthread), under what scenario would just one of those keys get compromised?

You only need one private key per device to be secure. The benefit of using separate keys per service is privacy - it prevents the various service providers from colluding to determine that you're a user of all the services (but if you're not careful you're probably leaking other information to them that would let them learn this anyways).

If you're not using passphrases on your keys, then yes they are locally wide open, much like a passwords.txt strategy for passwords. If you do passphrase them, the attacker now needs N passphrases. Perhaps you notice the keylogger before all passphrases get logged? There are probably more scenarios where N keys is strictly better than one, but that's the first that comes to mind.

I agree with the privacy aspect, it's that's the same point that the8472 made.

"perhaps you don't use password manager and you notice the keylogger halfway through" is a pretty unlikely scenario to motivate me to use a bunch of unique passphrases.

It's not "strictly better" when it hurts your ability to use and memorize strong passes.

Usability is part of security.

Here's what I do:

    # IdentityFile magic, should be placed at very end of file
    Host *
    IdentityFile ~/.ssh/keys/id_ecdsa_%r@%h
    IdentityFile ~/.ssh/keys/id_rsa_%r@%h
    IdentityFile ~/.ssh/keys/id_ecdsa_ANY@%h
    IdentityFile ~/.ssh/keys/id_rsa_ANY@%h
    IdentityFile ~/.ssh/keys/id_ecdsa_%r@ANY
    IdentityFile ~/.ssh/keys/id_rsa_%r@ANY
    IdentityFile ~/.ssh/keys/id_ecdsa_ANY@ANY
    IdentityFile ~/.ssh/keys/id_rsa_ANY@ANY

Will look for user@host, ANY@host, user@ANY, then ANY@ANY keys. You can add ed25519 to this.

This looks pretty neat -- however, do you use passphrases for your keys, and if so, how do you manage them? Only 2 obvious solutions spring immediately to mind - use the same (or none) pass for each key, or have a unique one per-key and some sort of separate password database with a master password.

At least, I can't imagine memorising enough unique passphrases for all the user/host combinations I currently have.

I'm hoping there's some clever built-in or easily added (like keychain/agent) way to secure individual keys on the filesystem without excess complexity when using them.

The IdentifyFile directives actually work with ssh-agent - it will try the keys listed there first, using them via the agent if they're loaded. I use the same passphrase on all keys and load them into my agent all at once (when loading, the last passphrase you entered will be tried to decrypt each key).

Normally, the problem with having many keys in the agent is that a server you're logging into will boot you after supplying too many keys it doesn't accept, but this fixes that.

> 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.

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.

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 , "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.

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

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.

You're right, I was wrong. Sorry!

AIUI A SSH session first performs a DH key exchange and authenticates the server. Only over that already-encrypted session will the client offer its public keys.

That means the public key will not be leaked to outside observers. Combine with server-specific keys to avoid potential "try logging into my server" social engineering.

This means only the server will ever learn your public key, but it has to know that already anyway.

So publishing your public key does not leak any privacy bits.

You're right, my bad.

>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.

Reply on news.ycombinator.com