Modern gnupg.conf setup

[Robert J. Hansen]

> Hey, I recall back in the days there were lots of online tutorials about
> how to strengthen your GnuPG configuration. I'm setting up my gnupg.conf
> environment and I was wondering which of these options still apply for
> todays standards (GnuPG v2.2).

The standard advice still applies: unless you know what you're doing and
why it's necessary, just stick with the defaults.  :)  GnuPG 2.2 runs
quite well with a minimal config.  That said, I'll try to answer your
question!

> no-emit-version
> no-comments
> export-options export-minimal
> keyid-format 0xlong
> with-fingerprint

All still valid, all still useful.

> list-options show-uid-validity
> verify-options show-uid-validity

Valid.  Whether they're useful depends a lot on your personal needs.  I
don't have much use for them, but your needs might be different from mine.

> personal-cipher-preferences AES256
> personal-digest-preferences SHA512

Please don't: you're possibly harming interoperability.  Although AES256
is a strong and well-supported cipher, you'll find other people who
don't have it listed on their key preferences.  In that case, you will
silently degrade to 3DES, which is widely considered the worst cipher in
OpenPGP.  It's slow, it's inefficient, and it has inherent risks when
encrypting large files due to its 64-bit block size.

(It is also overengineered like a Soviet workers' housing bloc.  No one
is aware of any cryptographic attacks on it, other than when used with
very large files.  Still: slow and inefficient.)

Likewise, if you encounter someone who for whatever reason can't use
SHA512 (like if they're using the old, but still encountered, PGP 8.1),
you will silently degrade to using SHA-1, which I don't think you want
to do.

Instead, try this:

personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192
CAMELLIA192 AES CAMELLIA128
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160

This way, if your correspondent can't use AES256 GnuPG will degrade to
the (strong, modern, fast) CAMELLIA algorithm.  If that's a no-go,
degrade to the (strong, modern, fast) 256-bit TWOFISH algorithm.  If the
256-bit ciphers are all a no-go, it degrades to 192-bit AES and
CAMELLIA, then the 128-bit variants.  Only if *no* modern cipher is
available will it then degrade to 3DES.

The same logic applies to SHA512.  It will exhaust all the modern hashes
before degrading to the (old, probably not very reliable any more, but
still better than SHA-1) RIPEMD160 algorithm, and only if all of them
are a no-go will it fall to SHA-1.

> default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
> TWOFISH ZLIB BZIP2 ZIP Uncompressed

Why do you prefer 128-bit AES over 256-bit TWOFISH?

> cipher-algo AES256
> digest-algo SHA512

*These are probably bad ideas.*  These say "screw what I just said about
my preference lists, ONLY use AES256 and SHA512" -- which can make your
message traffic non-interoperable with people who, for whatever reason,
cannot use AES256 or SHA512.

> cert-digest-algo SHA512

Still valid, still useful.

> compress-algo ZLIB

Scratch this for the same reasons as scratching "cipher-algo" and
"digest-algo".  Let GnuPG use a compression algorithm your correspondent
can actually use: don't force GnuPG to use one your correspondent can't use.

20 years ago it was widely believed compression before encryption was a
good idea.  Today that belief is pretty much shot, given how most file
formats already incorporate compression.

You can remove this line entirely.

> disable-cipher-algo 3DES IDEA CAST5 Blowfish

3DES is a MUST algorithm, according to the spec.  If you want to disable
the others that's your business -- but it's already implicit by not
including them in your personal-cipher-preferences.  This line can be
removed entirely.

> weak-digest SHA1

Again, SHA-1 is a MUST.

> s2k-cipher-algo AES256
> s2k-digest-algo SHA512

These are implicit given your personal-cipher-preferences and
personal-digest-preferences, and can be removed.

> s2k-mode 3

This is the default, and as such it can be removed.

> s2k-count 65011712

I have never found any use for cranking s2k-count this high.  I'd
suggest removing this line and using the defaults unless you have a
specific need for such a high count.