Usability of OpenSSL vs GNUPG
I've been playing around some with OpenSSL recently, and it seems to me that the OpenSSL command structure is rather convoluted. I've read a number of articles, blog posts, etc. that criticize GNUPG and even make the case that people should stop using it, in large part because of concerns around the GNUPG command structure and general usability. Yet I can't recall encountering any similar complaints about OpenSSL. I find this somewhat curious, and am wondering if there are OpenSSL detractors out there that I simply haven't come across or if the OpenSSL command structure isn't as complicated as it seems to me. Or if it seems to others that OpenSSL doesn't get the same level of criticism as GNUPG does for usability, although the tools seem to offer a generally similar user experience. I suppose that OpenSSL is geared toward a very technical and security-aware user base, who aren't likely to complain about usability issues - while GNUPG is a tool that could be used by all sorts of users, some of whom are definitely not technically inclined or interested in details of information security. That alone could explain the difference, I suppose. But I'm wondering if anyone has any other thoughts around this topic. Thanks, Dave ___ 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
Re: gnupg private-keys encryption
> How can I control the encryption on the private-key? Change the passphrase. Just changing configuration file preferences doesn't change the way the key is stored on disk. It only says "the next time you have to alter the way the key is stored on disk, use these new parameters". Changing the passphrase on the key will force GnuPG to write it out to disk again, at which point your new preferences will take effect. Warning: this information was correct for GnuPG 1.4 and 2.0. I'm not sure about 2.2, as I've never needed to do it on 2.2. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
