2

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]
      5DE3E0509C47EA3CF04A42D34AEE18F83AFDEB23
uid           [ unknown] GitHub (web-flow commit signing) <noreply@github.com>
$ touch example.txt
$ gpg -ear noreply@github.com example.txt
gpg: error retrieving 'noreply@github.com' via Local: Unusable public key

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

sanmai
  • 414
  • 3
  • 10

2 Answers2

5

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

Community
  • 1
forest
  • 64,616
  • 20
  • 206
  • 257
  • 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 08 '19 at 03:07
  • @sanmai That feature is a false sense of security. It is possible to [discover the actual recipient](https://security.stackexchange.com/a/186310/165253) even with that flag set due to how RSA works (via the so-called German Tank Problem in mathematics). – forest Apr 08 '19 at 03:08
  • Right, that's why I say "some" plausible deniability. – sanmai Apr 08 '19 at 03:10
  • @sanmai Sure. My overall recommendation would just be to use short-lived subkeys and destroy them every week/month. It's far better than nothing and still provides a decent level of forward secrecy, at the expense of people who communicate with you needing to keep their keyrings up to date. – forest Apr 08 '19 at 03:11
  • That's an idea! Should I revoke these subkeys after they expire? – sanmai Apr 08 '19 at 03:12
  • 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 08 '19 at 03:13
  • 1
    Understood, thank you very much for the explanation. – sanmai Apr 08 '19 at 03:24
0

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 <lastname@example.com>" 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 lastname@example.com 
-----BEGIN PGP MESSAGE-----
...
-----END PGP MESSAGE-----

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 lastname@example.com with some sensible revocation reason. We have now:

$ gpg -k --list-options show-unusable-subkeys
/tmp/tmp.4T2tY2qhj1/pubring.kbx
-------------------------------
pub   ed25519 2018-04-11 [C]
      <skip>
uid           [ultimate] Firstname Lastname <lastname@example.com>
sub   cv25519 2019-04-11 [E] [revoked: 2019-04-11]

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

$ echo | gpg -ear lastname@example.com
gpg: error retrieving 'lastname@example.com' via Local: Unusable public key
gpg: error retrieving 'lastname@example.com' via WKD: No data
gpg: lastname@example.com: 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.

sanmai
  • 414
  • 3
  • 10