Re: Modern gnupg.conf setup
On 15. 12. 19 19:32, Robert J. Hansen wrote: > >> It seems I was right to have asked here after all. It's amazing how many >> outdated tutorials exist... > > That presumes they were ever accurate in the first place. Many of them > were not. > >>> personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 >>> CAMELLIA192 AES CAMELLIA128 >>> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 >> >> Should these also be included in the default-preference-list? I think >> the latter is only used when generating new keys (setpref), yes? > > Not necessarily. Personal-cipher-preferences is the list of ciphers > you're willing to use, but the list of ciphers on your key (what's put > there via setpref) is the list of ciphers you ask *other people* to use. > > Will they often be the same? Yes. But not always, and there's a > subtlety there that's often overlooked. You might be willing to > generate traffic using ciphers you're not willing to accept. > cert-digest-algo SHA512 >>> >>> Still valid, still useful. >> >> This I'm uncertain about. Should probably be removed too? > > Probably not. > > The reason why cipher-algo and digest-algo are recommended against is > because GnuPG already has a robust mechanism for choosing a strong > cipher that you're willing to generate (via personal-cipher-preferences) > and the recipient is willing to receive (via prefs on the key). > > There is no such mechanism for certificate signatures. That's entirely > generated by you. You have zero knowledge of what algorithm other > people will use. If you want maximum interoperability, you have to use > SHA-1; everyone can read SHA-1 signatures. > > But that's SHA-1, and SHA-1 isn't exactly a highly recommended digest > any more. > > Use something better and stronger. SHA512 is probably the best option > right now. If someone can't read your certificate signatures, well -- > that's on them: they should be moving away from SHA-1. > >> The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be >> implemented, but the reason I included these is because I read on some >> websites that you do NOT want to use these at all due to their >> weaknesses and there should be some way of warning the user that weak >> algorithms are being used. > > I question the credentials of anyone calling 3DES "weak". It has one > and only one serious cryptographic weakness: due to its 64-bit block > size, it should not be used to encrypt more than about 4Gb of data with > the same session key. > > 40 years after it was first released, the best attack on it is a > meet-in-the-middle that requires -- hand to God, I am not making this up > -- 64 pebibytes of RAM, 2**112 operations, and several strategic nuclear > weapons to generate enough energy to run the computer. > > Let me repeat: I am not making that up. > > So, yeah, if your attacker has technology straight out of _Star Trek_ > and is willing to cause untold ecological catastrophe, you're hosed. > Otherwise, 3DES is still solid. > > That's not to mean it's perfect. It's not. It's slow, it shouldn't be > used to encrypt bulk data due to its 64-bit blocksize, and more. There > are lots of reasons to prefer other, better ciphers than 3DES. And > maybe I can understand people calling it "weak" because really, that's a > lot easier for people to understand than talking about block sizes and > clock-cycles-per-block and everything else. > > But it's *not weak*. And any website that tells you to avoid 3DES > because it's weak is, to be honest, either too ignorant to be taken > seriously, so patronizing they'll handwave away complex issues behind > the comforting veneer of "it's weak", or is outright lying to you. > > SHA-1, on the other hand... > > *At the present moment* SHA-1 is still trustworthy in the places where > it's baked into the RFC4880 spec. The attacks against it don't affect > the (few) places where it's baked into OpenPGP. But attacks can get > better quite suddenly, and it's a good idea to avoid SHA-1 whenever > possible. > > But please don't use weak-digest on SHA-1. The only thing it'll do is > drown you in false positives. 99.999% of the time when you get a > warning of "SHA-1 is being used You asked me to warn you about > it!", in fact nothing is amiss at all. > > A 'warning' that's wrong 99.999% of the time is worse than receiving no > warning at all. > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Hey, thanks for all the help. That was really an educational read. I ended up with this config file contents: keyid-format 0xlong with-fingerprint personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed cert
Re: Modern gnupg.conf setup
> It seems I was right to have asked here after all. It's amazing how many > outdated tutorials exist... That presumes they were ever accurate in the first place. Many of them were not. >> personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 >> CAMELLIA192 AES CAMELLIA128 >> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 > > Should these also be included in the default-preference-list? I think > the latter is only used when generating new keys (setpref), yes? Not necessarily. Personal-cipher-preferences is the list of ciphers you're willing to use, but the list of ciphers on your key (what's put there via setpref) is the list of ciphers you ask *other people* to use. Will they often be the same? Yes. But not always, and there's a subtlety there that's often overlooked. You might be willing to generate traffic using ciphers you're not willing to accept. >>> cert-digest-algo SHA512 >> >> Still valid, still useful. > > This I'm uncertain about. Should probably be removed too? Probably not. The reason why cipher-algo and digest-algo are recommended against is because GnuPG already has a robust mechanism for choosing a strong cipher that you're willing to generate (via personal-cipher-preferences) and the recipient is willing to receive (via prefs on the key). There is no such mechanism for certificate signatures. That's entirely generated by you. You have zero knowledge of what algorithm other people will use. If you want maximum interoperability, you have to use SHA-1; everyone can read SHA-1 signatures. But that's SHA-1, and SHA-1 isn't exactly a highly recommended digest any more. Use something better and stronger. SHA512 is probably the best option right now. If someone can't read your certificate signatures, well -- that's on them: they should be moving away from SHA-1. > The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be > implemented, but the reason I included these is because I read on some > websites that you do NOT want to use these at all due to their > weaknesses and there should be some way of warning the user that weak > algorithms are being used. I question the credentials of anyone calling 3DES "weak". It has one and only one serious cryptographic weakness: due to its 64-bit block size, it should not be used to encrypt more than about 4Gb of data with the same session key. 40 years after it was first released, the best attack on it is a meet-in-the-middle that requires -- hand to God, I am not making this up -- 64 pebibytes of RAM, 2**112 operations, and several strategic nuclear weapons to generate enough energy to run the computer. Let me repeat: I am not making that up. So, yeah, if your attacker has technology straight out of _Star Trek_ and is willing to cause untold ecological catastrophe, you're hosed. Otherwise, 3DES is still solid. That's not to mean it's perfect. It's not. It's slow, it shouldn't be used to encrypt bulk data due to its 64-bit blocksize, and more. There are lots of reasons to prefer other, better ciphers than 3DES. And maybe I can understand people calling it "weak" because really, that's a lot easier for people to understand than talking about block sizes and clock-cycles-per-block and everything else. But it's *not weak*. And any website that tells you to avoid 3DES because it's weak is, to be honest, either too ignorant to be taken seriously, so patronizing they'll handwave away complex issues behind the comforting veneer of "it's weak", or is outright lying to you. SHA-1, on the other hand... *At the present moment* SHA-1 is still trustworthy in the places where it's baked into the RFC4880 spec. The attacks against it don't affect the (few) places where it's baked into OpenPGP. But attacks can get better quite suddenly, and it's a good idea to avoid SHA-1 whenever possible. But please don't use weak-digest on SHA-1. The only thing it'll do is drown you in false positives. 99.999% of the time when you get a warning of "SHA-1 is being used You asked me to warn you about it!", in fact nothing is amiss at all. A 'warning' that's wrong 99.999% of the time is worse than receiving no warning at all. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modern gnupg.conf setup
Thank you kindly for your very informative answers. It seems I was right to have asked here after all. It's amazing how many outdated tutorials exist i.e. googling for "perfect pgp keypair" gives at least three "wrong" articles among the top few results. Having read the GnuPG docs a bit it appears a lot of options I listed are already enabled by default by a recent gpg, so I removed them. On 15. 12. 19 01:31, Robert J. Hansen wrote:> > Instead, try this: > > personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 > CAMELLIA192 AES CAMELLIA128 > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 > Should these also be included in the default-preference-list? I think the latter is only used when generating new keys (setpref), yes? Alas: personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 default-preference-list SHA512 SHA384 SHA256 SHA224 RIPEMD160 AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 ZLIB BZIP2 ZIP Uncompressed >> cert-digest-algo SHA512 > > Still valid, still useful. > This I'm uncertain about. Should probably be removed too? The documentation says: --cert-digest-algo name Use name as the message digest algorithm used when signing a key. Running the program with the command --version yields a list of supported algorithms. *Be aware that if you choose an algorithm that GnuPG supports but other OpenPGP implementations do not, then some users will not be able to use the key signatures you make, or quite possibly your entire key.* Source: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options >> 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. > The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be implemented, but the reason I included these is because I read on some websites that you do NOT want to use these at all due to their weaknesses and there should be some way of warning the user that weak algorithms are being used. disable-cipher-algo 3DES weak-digest SHA1 If some client can't support newer algorithms like SHA-2 and AES then it's better if that person upgraded their software rather than continue to use SHA-1 and 3DES. Best regards, Mistave. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modern gnupg.conf setup
On Sat, Dec 14, 2019 at 11:18:32PM +0100, Defiant wrote: Hey, I recall back in the days there were lots of online tutorials about how to strengthen your GnuPG configuration. I don’t know which tutorials exactly you’re referring to, but I have seen several of them myself, and I have always had the feeling that they were written by people who couldn’t be bothered to check what GnuPG’s default configuration actually is before deciding it needed to be ”strengthened”… no-emit-version no-comments Not needed, those are the defaults. export-options export-minimal That’s up to you. Note, this does not actually “strengthen” anything. keyid-format 0xlong with-fingerprint For information, the default is not to display any key ID (either short or long) but to display the full fingerprint instead (which makes displaying the key ID quite irrelevant). Setting keyid-format to either “short” or “long” however has the effect of forcing GnuPG to display the key ID of *subkeys*, so if that’s something you need, you may keep that line. list-options show-uid-validity verify-options show-uid-validity Already enabled by default. personal-cipher-preferences AES256 The default is AES256, AES192, AES128, 3DES. Note that you cannot remove 3DES which is mandatory as per the RFC 4880 (that’s the only algorithm which is guaranteed to be supported by any compliant OpenPGP implementation): even if you do not include it, GnuPG will silently add it back. By removing AES192 and AES128, you’re actually increasing the risk that GnuPG will have to fallback to 3DES if AES256 is not supported by the other party. I don’t think this is what you want. personal-digest-preferences SHA512 The default is SHA256, SHA384, SHA512, SHA-224, SHA1, with SHA1 being mandatory. Same problem as above: by limiting GnuPG’s options, you are increasing the risk of having to fallback to SHA1. default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES TWOFISH ZLIB BZIP2 ZIP Uncompressed This is almost exactly the default list, except that the default list does not include TWOFISH. cipher-algo AES256 digest-algo SHA512 cert-digest-algo SHA512 compress-algo ZLIB You are basically bypassing the whole preference-based mechanism used to select algorithms compatible with your recipients’ implementation. Almost certainly a bad idea unless you are operating in a context where you know you don’t need to care about interoperability (e.g. if you are only encrypting files for yourself). disable-cipher-algo 3DES IDEA CAST5 Blowfish weak-digest SHA1 3DES and SHA1 are mandatory as said above. The other algorithms are already not used by default. s2k-cipher-algo AES256 s2k-digest-algo SHA512 s2k-mode 3 s2k-count 65011712 The default S2K mode is already 3 (iter+salt). As for the S2K count, for information the default is a value automatically determined by GPG Agent so that, on your computer, running the S2K algorithm will take ~100ms. Overall I’d say most of your configuration is either uneeded or even counterproductive. I’ll quote GnuPG’s FAQ [1]: Does GnuPG need to be ‘tuned’ before use? No. GnuPG has sensible defaults right out of the box. Cheers, - Damien [1] https://gnupg.org/faq/gnupg-faq.html#tuning signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modern gnupg.conf setup
> 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
Modern gnupg.conf setup
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). Thanks. no-emit-version no-comments export-options export-minimal keyid-format 0xlong with-fingerprint list-options show-uid-validity verify-options show-uid-validity personal-cipher-preferences AES256 personal-digest-preferences SHA512 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES TWOFISH ZLIB BZIP2 ZIP Uncompressed cipher-algo AES256 digest-algo SHA512 cert-digest-algo SHA512 compress-algo ZLIB disable-cipher-algo 3DES IDEA CAST5 Blowfish weak-digest SHA1 s2k-cipher-algo AES256 s2k-digest-algo SHA512 s2k-mode 3 s2k-count 65011712 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
