laying groundwork for an eventual migration away from SHA1 with gpg

Micah Anderson micah at
Thu May 14 15:46:10 CEST 2009

David Shaw <dshaw at> writes:

> I don't mean there are faster/easier/cheaper ways of doing this
> mathematically.  I mean boring old subterfuge like going to a
> keysigning party with a fake ID, claiming to be someone else.  I get a
> bunch of signatures, and I'm done.  It skips the whole difficult math
> problem.
> I'm all for strong crypto protection against impersonation, but when
> there is a non-crypto impersonation attack that has essentially the
> same end result as a crypto impersonation attack, and the non-crypto
> variant of the attack is vastly cheaper, faster, and easier than the
> crypto attack, I do start to wonder what the point is of putting a
> strong crypto defense against the crypto attack.

That is very true, and I appreciate you pointing this out. However, this
problem is a different problem that is not going to be solved by any
amount of crypto or strong hashing algorithms (in fact I would argue
that fixing social problems with technical solutions is always a dubious

The problem that *can* be solved here is the technical one, and holding
back that solution because there is a weaker link in the chain that the
gnupg OpenPGP implementation cannot solve doesn't seem like the right
answer to me. In fact, I'd argue that the human element is always going
to be the weaker link and always has been. Taking this position, I
wonder why we don't consider saving some CPU cycles and step back the
crypto, maybe even reverting to ROT13 because even that is tedious and
difficult for a human to do, when its probably easier to send some cash
off to the Transnational Republic to get a decent looking

> Certainly.  This is the sort of thing that reasonable people can
> disagree on.  I don't think that your plan is wrong or evil or
> anything like that.  I just worry it's rather eager to expunge SHA-1.
> The plan pushes a 3-month window to migrate to SHA-256 and revoke all
> earlier keys.  We're not particularly close to having any collision at
> all, much less the finesse necessary to "weaponize" that collision
> generating process into an attack on OpenPGP.  

I had a slightly different read of this plan than you did and I think
that subtlety is a source of the resistance here. My understanding was
that this plan was suggesting that the people (Debian Developers) who
make up the largest strongly connected set in the existing Web of Trust,
begin considering a transition. 

This seems a lot different from what I am gathering was your reading,
which seems to suggest that there be a 3-month window to expunge SHA-1
entirely from the universe. The timeline that I see detailed is much
more conservative than that, instead it seems to describe a timeline
that is for an individual who, after careful consideration, has decided
to go through a key transition. The timeline is based on an evaluation
of the timeline that the author went through when he did a transition.

In fact the whole document is couched in words like "prepare",
"consider", "move in an orderly fashion", "eventual", "carefully",
etc. I do not get the aggressive push, or the 3-month timeline that you
seem to have read from the plan. The author seems to understand that we
are not close to having a "weaponized" collision, but that it eventually
will be coming so we need to start thinking proactively, instead of
getting caught with our collective MD5 pants down (c.f. RapidSSL)

> There are a good number of ways to shoot yourself in the foot with
> GPG, and I've seen a good few of them in the past week or so.  I

I would like to know what these foot shots are, as I am sure other
people (especially in the comments of that blog post) would. You mention
the interoperability with software from 5 years ago as a potential
problem, can you detail some more of the others you've seen?


More information about the Gnupg-devel mailing list