Is it safe to publish public PGP authentication subkeys?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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 ;)

Answer 4

I think that publishing authentication keys simplifies phishing and MITM attacks. Someone malicious puts your key in authorized_keys and provides you with this server instead of your own (e.g. with DNS spoofing). Yes, this server won't be listed in you known_hosts and you could deduce forgery, but still.

There is another argument not to publish authentication keys — size. Note that both PGP and GnuPG are not happy with large photos. Any extra published data means more work for keyserver and other machines checking your signatures or encrypting data sent to you.

Note that you also have to publish your certify public key which you use to sign keys including (but not limited to) your own. But current PGP implementations allow certify usage for primary key only, and you can't export public subkey without its primary key, so your certify public key will be published anyway.

UPD: If someone invents GPG authentication for public or enterprise servers, like with X.509 certificates, but with GPG keys found in keyservers, then you can reconsider. There were some attempts, but it looks they're all dead now. But even if it happens I would create separate authentication subkey for such system and upload this subkey only.