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.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
