10

Suppose I have a PGP key set up as follows:

I have an offline master public/private keypair, which is set to only Certify, aka create subkeys and sign other people's keys.

Then I create three subkeys which I put on a Yubikey (with offline backups):

  • Signing key
  • Encryption key
  • Authentication key

The signing key will be used to sign messages and git commits.

The encryption key will be used for people to send me encrypted messages.

The authentication key will be used with gpg-agent --enable-ssh-support to use as ssh authentication to log into servers.

My question is:

Are there any negative (or positive?) security implications to publishing the authentication subkey (or all three public subkeys) to a keyserver?

My logic is that I'd only really need to publish the signing public subkey, so people can confirm my signatures, and my encryption public subkey, so people can send me encrypted messages.

No one from "the public" needs to know that I even have an authentication key because it will only be used in the authorized_keys file of my servers to allow me to log in without a password.

If someone were to break into a server and query the public keys in the authorized_keys file, they could look that up in the keyserver and find out that I, specifically, am using that server. Is this problematic or am I overthinking things?

5

By providing more keys to potential attackers than necessary, you are violating the principle of least privilege (why should anyone else have the privilege to view your public key?). If they don't have to know, there is no point in helping them deduct further information, e.g. the key type (RSA, ECDSA, ...) and size (e.g. 2048 bit) of your SSH key to find attack vectors. From this they could make more informed guesses about how you generally secure your systems, how fast you switch to new technologies and how paranoid you generally are (hmm, still using 1024 bit RSA? Oh, 512 bit ECDSA, interesting...).

Imagine at the moment of key generation you were not aware that a 512 bit RSA key can be cracked on a normal laptop nowadays. Attackers actively searching for such keys online would mark you as an easy target immediately. Or imagine you forget to ever replace that key and/or forgot about your server (or you're simply not alive anymore to make changes). In X years, the private part of your 2048 bit RSA key can be calculated on a more advanced computation system and the data you have on your server will be at risk. It may not affect you anymore, but maybe you store someone else's data who will still care about keeping it secret.

Of course those scenarios are very unlikely (except for using weak keys, that happens regularly to people; even a 4096 bit RSA key is worthless if the state of the entropy pool was bad, see how lacking the world is at generating good keys in this paper), and probably a bug in SSH will allow exploitation of your server before that key of yours will be cracked, but their probability is not zero, and you should at least consider them before publishing more data than you need to. If you've considered these scenarios, you should be fine, but we all know that nobody can predict all attack scenarios or implications, so it's easier not having to think about them at all.

If you need to upload your SSH auth key to look it up, e.g. for configuring a new server's authorized_keys file, better host it on a URL that is hard to guess, e.g. www.mydomain.com/download/myAwesomePublicSSHkey.pub

  • I was in agreement until the last paragraph... first of all, that doesn't look "hard to guess" URL, but more importantly, why not find a better way like secure email, usb stick, etc... putting anything on a web server means you should assume the whole world has a copy forever (search crawlers, etc). – Jonathan Cross Sep 23 '17 at 15:21
  • Point taken (although I'm pretty sure you wouldn't start bruteforcing URLs on a random server, hoping to find a public key). As long as directory listing isn't on, I'd feel safe storing public information like this for easy retrieval. – Anton Kaiser Sep 25 '17 at 2:04
  • Btw, the methods you listed require additional equipment (USB Stick) or tools (email client, PGP) to actually retrieve the key, which you may not have at hand in the discussed situations. If you're really paranoid, encrypt that file (i.e. passworded AES with 7zip) on the web server, Then you'll also know that nobody manipulated it. Again, I suggest to take the risk of storing your SSH public keys somewhere easy to remember and easy to retrieve, as that is more important than keeping the file 100% inaccessible to anyone at all costs (which means a lot added effort for you to get started). – Anton Kaiser Sep 25 '17 at 2:15
5
+25

Yes, your logic is sound. You only need to publish your public keys to allow people to both send you encrypted messages and check your signature. However, there is no reason to publish your public key for SSH, which is not to say that you could not do it anyways. It really does not affect your security either way. If someone does happen to acquire your public key, the only thing that it will allow them to do is identify the beginning of an SSH session from you, and that really should not bother you except under some sort of extreme scenario that I cannot fathom right now.

1

The security depends on your use case:

  • Can someone attack the server with your public authentication key?
    • No.
  • If someone breaks into your server, is he then able to know your email-address?
    • Yes. But maybe the person also finds out your email address without your public authentication key.
  • If someone gets your public authentication key from a key server, is the person able to find out at which server it is used?
    • I don't know but you might check it by looking at the details of your authentication key.
  • Is someone able to get your private authentication from your public key?
    • No, as long as the key is strong enough (e.g. >= 2048 Bit RSA)
  • Do you need to make it public ask yourself all these questions?
    • It depends on your use case ;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.