please give us safer defaults for gnupg

[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.  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.  :)

> 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 am an amateur racer.  (My suicide ride of choice is my Mustang GT.)   
This is exactly the behavior I want in a race car and exactly what I  
*don't* want a novice driver to do.  A novice driver should be put  
behind the wheel of a limited vehicle, and those limitations should  
not be removed until such time as the driver demonstrates his or her  
skill behind the wheel.  I will not share a track with you at 225kph  
without first seeing you demonstrate your skills at 150kph.

The idea of giving a powerful and non-limited tool to a new user is  
sort of like putting a new driver behind the wheel of a Jaguar XJ220.   
Within an hour you'll have a dead driver and a smoking wreck that used  
to be worth half a million quid.  What you call "limits" are, in  
reality, carefully chosen behaviors meant to keep new users safe from  
their own mistakes.  I do not believe it is wise or ethical to tell  
new users they need to erase their margin for error.

> 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."  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.  Until that new revision is published, GnuPG is choosing  
to maximize interoperability.

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

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

> 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.  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?  The problem with assuming  
the existence of science-fiction level attacks is that once you start  
there's no reason to stop.

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

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