Will I be disapproved of or get frowned upon a lot if I choose to deploy and use GnuPG without an encryption key? E.g. I generate keys manually and skip the encryption key entirely.

The reason is that I do not plan to receive encrypted communications with GPG mainly because of the lack of PFS, which feature almost everything else offers nowadays. Even the very this website comes with PFS. Not even mentioning the anecdotal inconvenience receiving encrypted emails out of blue. What was very good in 1991, isn't so good in 2019. (No offence though! It's just OpenPGP wasn't designed with PFS in mind.)

Well, considering the above I could have just moved on if not GnuPG misbehaving funnily if there's no encryption key, which makes me think if there could be an actual important technical reason I really should be getting myself an encryption key. Is there?

For example, given a known encryption-incapable public key, GPG reports an error and waits for more input indefinitely:

$ gpg --version
gpg (GnuPG) 2.2.12
libgcrypt 1.8.4
$ gpg --recv-key 4AEE18F83AFDEB23
$ gpg -k 4AEE18F83AFDEB23
pub   rsa2048 2017-08-16 [SC]
uid           [ unknown] GitHub (web-flow commit signing) <[email protected]>
$ touch example.txt
$ gpg -ear [email protected] example.txt
gpg: error retrieving '[email protected]' via Local: Unusable public key

Else should I be using other means to announce that I don't want things encrypted in my name?

2 Answers 2


It is entirely acceptable to forgo creating an encryption subkey, if you do not wish to use GnuPG for encryption. There is no technical reason why this would be impossible, problematic or otherwise out of the ordinary. The OpenPGP standard is designed for encryption and/or signing, and quite a few people use it only for the latter. This is especially common when someone is posting to a mailing list or a public forum, as there is no one intended recipient, but cryptographic authenticity is still important.

The OpenPGP standard lacks forward secrecy because it is fundamentally impossible to do correctly using a protocol for asynchronous, indefinitely-delayed communication. There are tricks to get the same benefits as forward secrecy to a limited extent, such as by using short-lived subkeys and destroying them after use. There is also a draft extension for providing forward secrecy in OpenPGP.

The primary reason that forward secrecy is difficult to achieve is because it requires using ephemeral keys that are only kept as long as they are needed. In the case of a asynchronous email exchange, someone would need to give you their public key and you would need to encrypt with it and send them the reply. They would then destroy the corresponding private key immediately after using it to decrypt your message. The problem with this is the fact that they don't know when you're going to send a reply. They can't just keep the private key in memory only, or shutting down the computer would render any message you encrypt useless. They can't store it on disk, or issues like wear leveling and sector remapping may cause traces of it to remain, even after "secure deletion".

  • There's also --hidden-recipient to somewhat work around missing PFS with some plausible deniability, but I have no control on whenever my party will use it or not. Not good.
    – sanmai
    Apr 8, 2019 at 3:07
  • @sanmai That feature is a false sense of security. It is possible to discover the actual recipient even with that flag set due to how RSA works (via the so-called German Tank Problem in mathematics).
    – forest
    Apr 8, 2019 at 3:08
  • Right, that's why I say "some" plausible deniability.
    – sanmai
    Apr 8, 2019 at 3:10
  • 1
    @sanmai There's no need to manually revoke them, since they'll expire anyway. As long as you destroy the subkeys at their expiration, at least (which is necessary for the "secrecy" part of forward secrecy). In theory, you could even create a new subkey for each person you talk to and destroy it after the conversation is done, but that requires your correspondents to keep an even more up to date version of their keyring.
    – forest
    Apr 8, 2019 at 3:13
  • 1
    Understood, thank you very much for the explanation.
    – sanmai
    Apr 8, 2019 at 3:24

If you wonder if having an expired or revoked encryption key is any better...

Let's craft some expired keys:

export GNUPGHOME=$(mktemp -d)
faketime -f -1y gpg --batch --passphrase '' \
    --quick-generate-key "Firstname Lastname <[email protected]>" ed25519 cert 2y
faketime -f -1y gpg --batch --passphrase '' \
    --quick-add-key $(gpg --list-options show-only-fpr-mbox --list-secret-keys | awk '{print $1}') \
        cv25519 encrypt 1m

(You should probably use --with-colons instead.)

If anyone tries to send an encrypted email, they're up for a failure. But a really persistent person still can get things encrypted:

$ echo | faketime -f -1y gpg -ear [email protected] 

Which can be decrypted still. As it should.

Worth noting that gpg will happily export an expired key (--list-packets can be used to verify), and import it too, only won't show in the list unless asked. So expiring an encryption key does not stop anyone sending you an encrypted message, provided they know there was a key. Not good.

Let's try with revoking. Add a new encryption key:

gpg --batch --passphrase '' --quick-add-key $(gpg --list-options show-only-fpr-mbox --list-secret-keys | awk '{print $1}') cv25519 encrypt 1w

And revoke it with gpg --edit-key [email protected] with some sensible revocation reason. We have now:

$ gpg -k --list-options show-unusable-subkeys
pub   ed25519 2018-04-11 [C]
uid           [ultimate] Firstname Lastname <[email protected]>
sub   cv25519 2019-04-11 [E] [revoked: 2019-04-11]

Similar output shown when importing the key. Encryption fails too:

$ echo | gpg -ear [email protected]
gpg: error retrieving '[email protected]' via Local: Unusable public key
gpg: error retrieving '[email protected]' via WKD: No data
gpg: [email protected]: skipped: No data
gpg: [stdin]: encryption failed: No data

But it seems to be no easy way to read a revocation reason.

Which makes me think that sticking to not having an encryption key at all is the surest way to send the message, for time being.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .