[PATCH] Make update_keysig_packet honour cert-digest-algo

[Micah Anderson]

Werner Koch <wk at gnupg.org> writes:

> On Tue, 12 May 2009 22:05, dkg at fifthhorseman.net said:
>
>> do the Right Thing proactively, well before the "weaponized" attacks are
>> created.  The tools we release this year will likely still be in use 5
>> years from now, in a different cryptographic landscape, on behalf of
>> those same users who don't understand the issues.
>
> We should get things back to reality.  
>
> First of all there is no attack on SHA-1.  Maybe it will be possible to
> mount a collision attack in a couple of years.  Maybe it will then be
> possible to attack the web of trust or do any other collision based
> evil.

I appreciate you bringing us back to reality(tm), grounding this
discussion is helpful. However, the first sentence of what you said was
grounded in reality, but then you immediately stepped into
speculation. You are right that 'maybe it will be possible to mount a
collision attack in a couple of years', but I would be just as right to
say that 'maybe it will be possible to mount a collision attack in a
couple of weeks'.... we do not really know where this will fall. I think
the 'reality' is that we can all agree that a collision attack on SHA-1
will come, *at some point*. It might be in 4 years, or it might be in 2,
or someone might be working on polishing their powerpoint slides right
now. 

The reality here is the following: the reduction in keyspace travel
could point to a trend similar to what happened with MD-5 (ie. further
reductions are to be expected). Based on this, we can expect that some
point SHA-1 will have a collision attack that is relatively trivial. At
the moment, we have a strong indication that collisions with SHA-1 are
within the reach of Well Funded Organizations, but we do not have the
actual published paper yet.

> This is nothing the average user needs to care about.  We don't need
> to prioritize pro-active changes of active keys either.

Ok, if this is nothing that the average user needs to care about, then
what does the gnupg development need to think about? I don't want to
claim that interoperability is not important, but I do think that gnupg,
as the flagship free OpenPGP implementation, should take the responsible
lead and push the Web of Trust to do the right thing. GnuPG already
drives the WOT, and has the ability to nudge it in positive and
coherent directions, or not. 

We all recognize the reality that key transitions take a long time, a
really long time. Anyone who has done it understands this very well. We
know, without any conjecture, that there is no demonstrated problem
right now (if you ignore the fact that collisions in the key space are
now within the reach of Well Funded Organizations, which I personally do
not think is something that should be ignored in a cavalier
manner). Because there is no problem right now, we have the space to
work on this problem, without a hasty rush that could lead to
problems. 

Lets think a couple of steps ahead, be slightly cautious, and come out
the other end as having the foresight to deal with this problem
gracefully before it hit us. Lets actually plan for the future, instead
of deferring that planning. 


>  - The web-of-trust is an ad-doc structure and its security margin is
>    for sure far far less then 2^52.  Attacking the WoT is far easier
>    than mounting an collision attack on SHA-1.  Even without doing
>    rubber hose cryptanalysis.
>
>  - There are tools implementing the security (e.g. gpg).  Assuming that
>    these tools are bug free or at least that these bugs are harder to
>    find and exploit than to mount a real world SHA-1 collision attack,
>    is plainly wrong.  Those who believe that should do a reality check.
>
>  - There are other application on the box running the tools: Are they
>    secure enough?  I doubt that.
>
>  - There is an operating system involved.  Is it really secure enough?
>    I doubt that too.
>
>  - I guess that at least 99 percent of all users are not able to keep
>    their environment hardened against simple attacks.

There are always going to be other weaknesses, but thats not an excuse
for gnupg to not try to be better. All of these things need to be
improved, but doing so is not the role of gnupg. This list is for gnupg
development, not a list about Windows security, or whatever. Each one of
these pieces does need work, I'm not going to dispute that, but that
work should not lull gnupg into inaction. Gnupg has its role to play and
it should take that role and run with it, blazing the crypto trail. 

> Why should we then harden the existing keys automagically and risking
> interoperability problems which will in turn lead to decreased security.

I may be an outlier here, but those 5-year old programs that will have
interoperability problems are going to have other issues that
significantly reduce their security. We should not let old software that
has *worse* security holes hold us back. We *can* lead and people *will*
upgrade.

At some point Firefox was also faced with this decision: should they
push for a better web, knowing that they will cause the older browsers
to have interoperability problems with modern websites? The answer was
yes. We dont need a world filled with IE3 and Netscape Navigator any
more, anymore than we need encryption tools that provide a false sense
of security.