please give us safer defaults for gnupg

[adrelanos]

Robert J. Hansen:>> We think...
>
> If you're writing on behalf of a group, I would love to know the name of
> the group and the names of its members.

Understandable. At the moment it's just one person sharing that opinion.
[Didn't ask many more yet.] I asked if I am allowed to tell names,
probably yes, soon.

> Otherwise, I can only assume
> you are suffering a mental illness and are speaking for the multiple
> voices in your head -- either that or else perhaps you're fighting off a
> parasitic infestation and are speaking on behalf of your guests.  :)

:)

>> gnupg still is the most used and most important encryption tool
>> in the Free Software community. [1]
>
> It is definitely not the most-used, and it is likely not the
> most-important.  OpenSSL is free software, and is used orders of
> magnitude more often than GnuPG.  I routinely go days without using
> GnuPG, but I rarely go even a few hours without accessing an
> OpenSSL-secured webpage.
>
> GnuPG is great, don't get me wrong -- but let's keep the hype in
> perspective.  :)

We don't use OpenSSL to encrypt our mails. I'd suppose, OpenSSL is
mostly used by users not being aware of it. While OpenSSL is probably
great, the CA implementation is not. And that's another story. I'd
always trust gnupg more than OpenSSL, but that's mostly for usability
reasons and because no contacts I know are waiting for OpenSSL encrypted
messages.

>> 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.
>
> Although you chose this metaphor, I'm not sure that it's a metaphor you
> really want to use.

I agree, it's not a good analogy. I'll try harder next time. However, I
trust you got my point.

>> gnupg comes with poor defaults...
>
> If GnuPG's defaults lead it to being subverted, then I agree it is a
> serious problem that will need remedy.  However, as near as I can tell
> that is not the situation.

>> 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 as long as GnuPG has existed people have been saying "use this
> gpg.conf file that I wrote in order to get the most security."

When I searched for this on search engines, I haven't found one in a
project's character. (I.e. were it's open for debate/pull requests/changes.)

> Very
> often these 'recommended' gpg.conf files are in conflict with someone
> else's 'recommended' gpg.conf file.
>
>> For example cert-digest-algo why is it in gpg still sha1 and not sha256
>> or sha512?
>
> Interoperability.  SHA-1's long-term prospects are not particularly
> good, but for now it is the only MUST digest algorithm in RFC4880.  The
> people developing RFC4880 are well aware of this problem and the choice
> of digest algorithms will be addressed in the next revision of the
> standard.

That's the point. I argue, that "we" [hopefully soon telling you the
other name and if not, other supporters sharing my standpoint]
prioritize working solutions which are as secure as possible rather than
waiting for some RFC to finish.

[Let's forget about the we until I maybe finished the letter after
clearing up some points.]

I'd also suppose [okay, I am risking false consensus here] that users of
other messengers with security in mind, such as bitmessage, pond,
retroshare, OTR [and probably others I am not aware of or have
forgotten] have a similar view on this.

> Until that new revision is published, GnuPG is choosing to
> maximize interoperability.

This is very unfortunate.

>> 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?
>
> Convenience.  You should always use a long key ID to retrieve a key, but
> there's nothing wrong with using a short ID to refer to an
> already-validated key.  The main risk of short ID collisions comes from
> people pulling the wrong certificate off the keyservers and mistakenly
> using that one; but when it comes to using keys you have already
> downloaded and validated the risk is minimal.

In my opinion, training users to get accustomed to insecure things and
then expecting them to do the right thing when necessary seems likely to
result in many users doing the wrong thing.

>> Update: now that long key ids can also be forged [8], why not show the
>> full fingerprint by default?
>
> Convenience.  See above.

>> 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?
>
> NIST's recommendation is that a 2048-bit key will be sufficient for the
> next 30 years.

Too short for me. I don't want anyone to dig up what I did 30 years ago.
Stuff that hasn't been deliberately stored in meanwhile should be forgotten.

> ENISA concurs in this judgment (although they recommend
> 3072-bit keys for reasons that are not particularly relevant here).  RSA
> Data Security also concurs.  Given the vast majority of cryptologic
> think-tanks in the world believe 2048-bit RSA will be secure for the
> next 30 years, GnuPG has taken the reasonable position of defaulting to
> 2048-bit RSA.

> With respect to "if creating 4096-bit keys just takes a few seconds
> longer and virtually make no difference when using these keys," as
> several people here have attested to in the past it makes a big
> difference for many users.  Mobile devices... embedded systems... sites
> that do bulk encryption... mailing lists... the list goes on.

I certainly know too little about mobile/emended devices to be sure it
really doesn't matter for them. But where should be the border? You're
not supporting MS-DOS users either and they're still around. So what is
the criteria here to say what the minimum system requirements should be?
In my opinion, users who're still using slow systems should choose the
"faster but less secure opt-in option" unless there are too many of them
in favor of the majority (?) of users who don't see any disadvantages
with 4096-bit 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.
>
> It is not necessary to take it for the sake of argument.  Compelling
> thermodynamic arguments exist that say we will not break 2048-bit RSA
> until we've had truly science-fiction level breakthroughs in computing
> technology.

>> Let's imagine, someone finds a
>> vulnerability in RSA being able to reduce the difficulty for brute force
>> by 1024 bit.
>
> This would be a science-fiction level breakthrough in mathematics.

Or just just someone having a clever idea no one else had before? Happens?

> If
> we can imagine a 1024-bit breakthrough, why not a 2048-bit, or a
> 3072-bit, or a 4096-bit, or a 16384-bit?

I don't know. Why where there 2 bit breakthroughs (happened for some
other algorithm) and not 4 bit?

> The problem with assuming the
> existence of science-fiction level attacks is that once you start
> there's no reason to stop.

scifi-gpg? ngpg? For Next Generation gpg? ;)

>> 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.
>
> I'm reminded of a _Simpsons_ episode where Lisa gives Homer a
> tiger-proof rock.  She points out to him that he's not being attacked by
> tigers, therefore the tiger-proof rock works.  Homer, being foolish,
> believes Lisa and asks to buy the rock from her.
>
> I do not believe it is ethical for us to be in the business of giving
> people tiger-proof rocks.  Even if it "reduces anxiety," as you put it,
> it's unethical.

It's not like you suddenly start selling snakeoil. For one, you wouldn't
have this discussion. ;)

>> We do not care about closed source PGP compatible software, namely,
>> well... Good question, it's difficult finding alternative
>> OpenPGP compatible software at all.
>
> McAfee has an offering, so does Symantec.  I know that at least one
> major telecommunications firm is using the most brain-damaged and
> minimalistic RFC2440 implementation on the planet.  There's
> BouncyCastle, there's Peter Gutmann's cryptlib, there's...

>> Can't remember having this seen anywhere ever.
>
> I'm part of the Enigmail team, and I field a fair number of help
> requests from users who are having trouble.
>
> I'm not sure this is the most common help request I see, but it's close:
> "I used this gpg.conf a friend of mine told me would give me the most
> security..."  Almost always, it uses cert-digest-algo, digest-algo or
> cipher-algo in a way that is seriously affecting interoperability.

What about liberating ourselves by forgetting about compatibility at
some point and starting fresh and most secure? By never breaking
compatibility, you can never reduce complexity. Less complexity means
more simplicity, thus perhaps more usability. In my experience, projects
that were created long after gpg are much more usable, probably because
they could learn from gpg which things do not work so well. And I am not
cynic here, because without gpg we wouldn't have that knowledge and also
not those other clients being so usable.

Robert, Werner, let me say that I value a lot, that you're discussion
these matters in public without taking offense even though our
standpoints are quite different. (Most likely due to our different
histories, knowledge, believes, etc.)

Please tell me, what kind of argument would you accept? I guess you'd
like to see loads of happy gpg users, gpg for the masses, etc. Would
numbers convince you? I mean, What if alternative projects such as
Bitmessage etc. managed to get far more users while gpg passes into
oblivion [while they objectively provide more/less security]?