> 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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users