[PATCH] Make update_keysig_packet honour cert-digest-algo

[Werner Koch]

On Thu, 14 May 2009 16:35, micah at riseup.net said:

> 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

Predicting the future is always speculation.  My point is that from an
attackers point of view there are far easier attack vectors than the use
of any kind of modern cryptanalysis.  We need to keep this in mind when
talking about the *immediate* need to change algorithms.

> 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

By the time we started the OpenPGP WG in fall 1997 it was already known
that MD5 had severe weaknesses.  Thus PGP5 and thus OpenPGP used the
best hash algorithm available at that time: SHA-1.  We knew that it
would not last forever and that SHA-1 doesn't match the strength of the
other algorithms; we eagerly waited for the SHA-2 series of algorithms
to get released by the NSA.  It is 6 years since we implemented them and
only now we can be somewhat sure that they are widely available.  Thus
we are now discussing how to make use of them.

Deploying a new algorithm takes time, a lot of time.  Peter Gutmann has
a paper on this topic.  We, the OpenPGP community, are quite good in
deploying new algorithms - way faster than other groups.

> 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

We are doing exactly this.  Deploying a code base which allows to use
newer algorithms without to much hassles.  This all started 6 years ago
with SHA-2, now continues by changing the default algorithms for new
keys and will eventually deprecate the default use of SHA-1 and
DSA-1024.

> 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

GnuPG has all features to use stronger algorithms; what we are
discussing are the default algorithms for users who are not security
experts and need something which just works and is secure enough for
their use cases.

> gracefully before it hit us. Lets actually plan for the future, instead
> of deferring that planning. 

As said we are doing exactly this.  We need to take some care because we
don't want to fall into the X.509/CMS trap where it took more than a
decade that the major applications achieved a little interoperability - on
the least common denominator.

> 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

Right, I listed them to show that it is much harder to deploy secure
systems than just replacing an algorithm.

> 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

It is not about Windows.  Windows is not worse than other major OSes.
Code quality is a major problem and unfortunately one which can't be
solved as "easily" as creating a more secure algorithm.

> 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

Maybe, we don't know.  GNU/Linux distributions usually keep on fixing
security bugs even for very old software.  GnuPG 1.2 reached end of
life a bit more that 4 years ago but it is still widely enough in use.
We even did a security update on our own 2 years after end of life.

Those who really need state of the art security will use a more recent
version.  The default key sizes are not a problem for them and they can
cope with possible interop problems.

> 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

<ot> Supporting EV certificates for a better web?  I beg to differ; they
are merely shoveling more coal into the the big certificate vending
machine. </>.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.