-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi!
[This was originally planed as an open letter, but I thought it might be better to hear your arguments beforehand.] We think gnupg still is the most used and most important encryption tool in the Free Software community. [1] But there is a big problem with gnupg's default config values. As an analogy, it is a somewhat usable racing car but it unfortunately comes with a limiter and you need to find out how to get rid of the limiter first. As a result many users mess up and use only the limited secure version. gnupg comes with poor defaults and since it is of that much importance, that is a problem. We even have a recommended gpg.conf in torbird's git repo. [2] [3] The fact that we even need such a thing is bad. For example cert-digest-algo why is it in gpg still sha1 and not sha256 or sha512? Now that a few people know, that short key ids can be easily forged [4], why isn't the keyid-format set to 0xlong by default? Update: now that long key ids can also be forged [8], why not show the full fingerprint by default? And why does gpg still create 2048 bit keys, if creating 4096 keys just takes a few seconds longer and virtually make no difference when using these keys? For the sake of argument, let's take it for granted, that 2048 bit is still secure enough and can not be broken with brute force. That doesn't take into account, that we now know, thanks to Eduard Snowden, that the NSA infinitively stores encrypted data until they develop methods to decrypt it. [5] Other organizations probably do that as well in case someone wants to make an argument "you can trust the NSA". Also that doesn't take into account, that the NSA is building a giant new center in Utah spending billions just for decrypting such messages (also verifiable in mainstream press [6]). Let's imagine, someone finds a vulnerability in RSA being able to reduce the difficulty for brute force by 1024 bit. In that case, we're much better off with a 4096 bit default rather than with a 2048 bit default. Having the advantages of such a change at hand (many) and comparing them with the cons (almost none), we think it's irrational not to crank up the default value to 4096 bit. Maybe let's add another weak argument to the mix. Part of using encryption software is reducing anxiety. Even if using 4096 bit instead of 2048 bit does little more than reducing anxiety, we'd argue, that reducing anxiety is a one of the tasks of encryption software. It also lets us focus on discussing more important things than this dull 2048 vs 4096 bit discussion. Those teaching others how to use gpg [at crypto parties etc.], won't have to understand why 2048 bit is the default, why some recommend to use 4096 bit or keep defending 2048 bit etc. Well, perhaps we understand little about interoperability and ignored that argument against cranking up the defaults. This is what we think about that... We do not care about closed source PGP compatible software, namely, well... Good question, it's difficult finding alternative OpenPGP compatible software at all. Probably there is only one product not based on gnupg, namely "Symantec Encryption Desktop". As long it was still called PGP Corp. and Philip Zimmermann was in charge, there was probably no backdoor. Now, that Symantec is in charge, a US company, and looking at the recent news... Quote guardian: "Through these covert partnerships, the agencies have inserted secret vulnerabilities – known as backdoors or trapdoors – into commercial encryption software" [7]. We don't see why, the Free Software community, should care about Symantec's OpenPGP. We are suggesting to just crank up the defaults - now. Maybe gpg should add a --compatible switch, where it uses weak default to be as inter-operable as possible. Oh, gpg already has switches such as --pgp6. Even better. We're all for Free Software / Open Source. Writing specification is even better. However, the specification process should be a bonus and not needlessly block improvements in security for years while we urgently need it. Alternative implementations (probably only Symantec) should be free to cope up. They can be even given a notification and few months to update their clients to the latest developments. But the pure existence of those shouldn't prevent us for years from getting secure defaults with no hope of improvement in sight. An argument against interoperability is, that using cranked up defaults creates few support requests. TorBirdy, Tails and Whonix are cranking up the gpg defaults. How many support requests of the type "recipient can't decrypt/verify my messages, because using an alternative OpenPGP implementation" do we have? Can't remember having this seen anywhere ever. We, the singers of this letter, are not all necessarily experts in cryptography or as knowledgeable about gnupg as the authors are. We give you the benefit of the doubt. It could very well be the case, that our hypotheses are totally wrong and that in fact defaults such as SHA1 and 2048 bit are totally fine for now and for ever. If that is case and/or if the interoperability argument is your standpoint, please remind the emotional argument of reducing anxiety. In that case, also consider cranking up the defaults just because security isn't worsened but due to popular request should enough people sign this letter. Rather please consider cranking up the defaults just for the sake of allowing (eventually in your view) paranoid and/or wrong people to reduce complexity of instructions. [7] That alone would probably help with a greater adaptation of gnupg. There would also be less room for conspiracy theories, why gpg is still using SHA1 and 2048 bit by default. We, the singers of this letter, are very thankful for everyone having contributed to gnupg and greatly respect them. Please take our positive criticism and crank up gpg's defaults, so people can make their instructions simpler (example [7]). The more there is to explain [7], the more difficult it becomes, and the more likely it becomes to mess up. All the best, adrelanos [1] That is hopefully beyond questioning. For example gnupg is used by major Linux distributions for package download verification, for the trust chain between developers and used by man Free Software developers to sign their releases. [2] https://github.com/ioerror/torbirdy/blob/master/gpg.conf [3] https://github.com/ioerror/torbirdy/pull/11 [4] http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html [5] Quote EFF "[...] More appallingly, the NSA is allowed to hold onto communications solely because you use encryption. Whether the communication is domestic or foreign, the NSA will hang on to the encrypted message forever, or at least until it is decrypted. And then at least five more years. [...]" from https://www.eff.org/deeplinks/2013/06/depth-review-new-nsa-documents-expose-how-americans-can-be-spied-without-warrant [6] https://en.wikipedia.org/wiki/Utah_Data_Center [7] Would be great if instrutions such as https://wiki.ubuntu.com/SecurityTeam/GPGMigration wouldn't require lines along "[...] Set defaults in ~/.gnupg/gpg.conf [...] cert-digest-algo SHA512 [...] default-preference-list SHA512 [...]". [8] http://debian-administration.org/users/dkg/weblog/105 -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJSrzpRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5 QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7v68MP/0pAsOVXHooY2TWjoeshYtyN nf2HUC2znVhj7d+o7jpatP9OdXU2IwgY9ODtbpnvDYE0b/IzEP9N33kgAjS7951b LO6KqXHP1RVbv953U84Ymuk+SM11QqNuov5rjdhmlj6vSAbOIbbajW4LYjsKnGQ5 SOp6aEsOWjgLwgtXV4JRWT1wuuPVz9NUSLWAkWmIMXWeTxuubJ+cXS1OJT7jZsz8 OazhLItAi+ENLOuS/KIw9NpcCtpZ/RZLQ4tkPpjuu97LdbddYv52EtY1k+Bz1bx+ fdBEkZzAfGuaJEtHwyl0pkJ69IDvLF1hMxH4zuOZwgXwFW8vdVR9YmHYZbG1wAGV aTKbrtDzgBCKeLiE2d3woknZ2umq4pVd+SnGFjtfu6ou987bgWqCj8q5Q8tP1s8D teCqXf3qHTEfsLT4khLfMMbv9enmA9W8iHEpFlUCJqvpnZuq5B2GgV7/IAH4Uski Fh/G2GnpcikJdR4OMWT1R+zHA31mQnUIBVdSieUbR17B0TjdtDSmi01MPhP6rl1F mVns4Gkko39+5eee1q7t7NgnaUIyotpeDkjzCCcRCKgNCcARUBwtZNuT7ekKpLfU YvT6Y9sYiLDRalobu4+VZPqdclSlZESsoMmKuUlHEPfz8pjZ1EvZJvE61UWb7Pld vdv4ioSzv+7VfEBeQIGL =gxuA -----END PGP SIGNATURE----- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users