please give us safer defaults for gnupg

Robert J. Hansen rjh at sixdemonbag.org
Tue Dec 17 02:34:31 CET 2013


On 12/16/2013 6:11 PM, adrelanos wrote:
> 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.)

Perhaps not, but you *did* find them.  Your original email referenced,
for instance, the Debian GnuPG migration guide, which makes its own
recommendations for what one's gpg.conf file should contain.  Websites
with their own recommendations for "how to *really* make GnuPG secure"
are a dime a dozen; most of them are put up by people who deeply
misunderstand GnuPG.  (The Debian guide is, fortunately, among the
better ones.)

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

Then you need to use some other tool.  Alternately, you could create
your own GnuPG distribution which installs a gpg.conf file tweaked the
way you want it -- but I personally find it unlikely that the changes
you seek will be incorporated into GnuPG's master branch.

> I'd also suppose [okay, I am risking false consensus here] that
> users of other messengers with security in mind...

After Richard Nixon was re-elected President in 1972, the _New York
Times_ film critic Pauline Kael exploded.  "Nixon?  Re-elected?  That's
impossible!  Nobody I know voted for Nixon!"

Nothing is less trustworthy than our supposition about the feeling of a
community far, far larger than we are.

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

This is not a vulnerability.

Assume, for sake of argument, that my friend has a long key ID of
0xDECAFBADDEADBEEF.  I verify the fingerprint, sign the certificate, and
thus validate it.  Someone else tries to trick me into a collision by
sending me a certificate signed with 0xBADD00D5DEADBEEF.  My email
client automatically downloads the certificate from the server.  I now
have two certificates with the shortID of 0xDEADBEEF...

... and absolutely zero risk.

My email client tells me whether a message is signed by a validated key
or an invalid key, so no one can use the (invalid) 0xBADD00D5DEADBEEF
key to trick me into believing it comes from the (valid)
0xDECAFBADDEADBEEF key.  And when encrypting a message for my friend,
GnuPG won't let me encrypt to 0xBADD00D5DEADBEEF because it's an invalid
certificate.

When certificates are properly verified and validated, the risk from
shortID (or even longID) collisions is effectively zero.  It's only when
one disables key validation checking, or improperly validates
certificates, that an attack surface becomes manifest.

> Too short for me.

Then use something other than GnuPG.

PGP was originally "Pretty Good Privacy."  Phil Zimmerman named it that
for a reason: it's pretty good.  It's not perfect and it won't be secure
forever.  GnuPG is built in that mold.

If you need perfect privacy, or forever privacy, you need to look
elsewhere.  GnuPG offers neither.

> So what is the criteria here to say what the minimum system 
> requirements should be?

I imagine it's something like, "If enough people complain to Werner
about how GnuPG is no longer usable on their system, Werner will know
the system requirements should be lowered."

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

At some point they're the same thing.  The point remains, though, that
we can't defend against science-fiction level attacks, nor is it
productive for us to try.  Because once you start imagining
science-fiction level attacks, where does it stop?

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

A 2-bit reduction is not a science-fiction breakthrough.  A 1024-bit
reduction would be.

> What about liberating ourselves by forgetting about compatibility at
> some point and starting fresh and most secure?

In 2000 I was a young software engineer living in San Francisco.  I was
considering applying for a job at a major, internationally-recognized
bank.  Before I sent in my resume, though, I talked to a friend who
worked there to ask about what kind of work I'd be doing.  My friend
told me the bank was undertaking a massive clean-slate project to get
rid of all their legacy COBOL code and replace it with modern,
well-designed, object-oriented Java.

I passed on the job.  To the managers at that bank, starting over from a
clean piece of paper sounded like the sort of thing that really should
be done.  To a software engineer, it sounds suicidal.  Those ancient
COBOL applications have been running with near-100% uptime for 50+ years
and last had a bug 20 years ago.  Getting rid of that is not the sort of
thing one does lightly, and never just because it seems like a good time
to do a clean-slate rewrite.

I think that if you consider this story, you will come up with what I
think of the idea of discarding RFC4880 and starting over from a clean
slate.  :)

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

My father is a federal judge who was asked to join FISA.  (He declined.)
I believe that, given my close association with the United States
government, a lot of people would stop trusting GnuPG if I were to ever
take a leadership or development role in GnuPG.  For that reason "what
kind of argument I would accept" is really kind of irrelevant -- you're
trying to convince Werner, not me.  All I do is answer questions, dude.  :)

(Also, it should follow that I am not speaking for Werner, nor for
GnuPG!  This email contains nothing except my own rambling opinions.)



More information about the Gnupg-users mailing list