please give us safer defaults for gnupg

[adrelanos]

-----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-----