30 September 2013
Why the Web of Trust Sucks
Date: Mon, 30 Sep 2013 15:07:49 +0200
From: Eugen Leitl <eugen[at]leitl.org>
To: cypherpunks[at]al-qaeda.net, info[at]postbiota.org,
Subject: [tor-talk] Why the Web of Trust Sucks
----- Forwarded message from Mike Perry <mikeperry[at]torproject.org>
Date: Sat, 28 Sep 2013 23:43:27 -0700
From: Mike Perry <mikeperry[at]torproject.org>
Subject: [tor-talk] Why the Web of Trust Sucks
Joel R. Voss:
> Hi Mike,
> I'm writing a blog post about web of trust. I'm looking for any weaknesses
> can find in it because I'm writing a piece of software that would be
> to help grow it. I'd appreciate if you could give me a few points that
> research. I'd be happy to send you my findings so far if you want to
> This is a fairly important subject because many people rely upon it
> software signing, encrypted e-mail, and soon we could use it much more
The web of trust has three main problems:
1. It leaks information.
This includes social graph metadata, time and place of interaction, and in
some cases government/slave-name identity. This issue has been discussed
at length, of course.
2. It has many single points of failure.
Because by default GPG uses shortest-weighted paths to establish trust in
a key, and moreover because nothing authenticates the *entire* Web of Trust
graph, each and every member of the "Strong Set" essentially functions as
a CA, especially for keys only weakly connected to the Strong Set. If you
compromise just one of those keys, you get to use that key to certify arbitrary
keys for any name you like.
To understand how and why this is a problem, let's walk through a typical
Web of Trust workflow.
Let's say we have a GPG user named Edward who wants to send an encrypted
email about the extreme level of corruption at his workplace to a journalist
that he has never met. Let's call that journalist Glenn. For the sake of
argument, let's say that both individuals are active participants in the
Web of Trust.
Edward also knows that the network systems administrators at his workplace
are very sophisticated, and intercept all encrypted communications for purposes
of active MITM attacks to obtain the communications content. So Edward decides
to download Glenn's key from subkeys.pgp.net, and requests that his gpg client
provide him with a trust value for Glenn's key.
Now, the network systems administrators at Edward's workplace have anticipated
this. They have a compromised HTTPS CA cert, as well as have compromised
a couple of highly trusted keys from the Web of Trust. Let's call one of
these GPG keys Roger.
When Edward goes to download a key to use for Glenn, the network systems
administrator gives him a new fake key that they generate on the spot. The
network systems administrator also attaches a fully trusted signature using
Roger's compromised key. They also block the actual key for Glenn from reaching
Edward's GPG client has trust in a couple keys. It turns out that one of
his trusted keys, Bruce, has full trust in Roger's key (the compromised key).
Edward's GPG client then computes a fully trusted path from Bruce to Roger
to the fake Glenn, and Edward then sends an encrypted email to fake Glenn
that is then subsequently read by the network systems administrator.
Game over for Edward :/.
This scenario is possible against arbitrary keys using any of the high degree
keys in the Strong Set. They effectively function as single point of failure
CAs for the Web of Trust, which destroy its utility as an independent key
3. It doesn't scale very well to the global population.
The amount of storage to maintain the Web of Trust for the whole world would
be immense. For the level of authentication it provides, it just doesn't
make sense to have this much storage involved.
So what should we do instead?
Well, I think it is important to take a step back and think about what the
Web of Trust is trying to accomplish. Aside from being a global popularity
contest and some kind of weird quasi-religious hacker ritual, it is an
authentication mechanism for the keys that you retrieve.
It turns out there are lots of ways to authenticate keys using multipath
authentication that do not suffer from the Web of Trust's downsides**.
Here's a few examples:
1. Every time GPG downloads a new key, re-download it several times via multiple
Tor circuits to ensure you always get the same key.
2. Every time I verify a signature from a key sent to an email address that
is not mine (like a mailinglist), my mail client adds a tiny amount of trust
to that key (since each new public email+signature downloaded represents
an observation of the key via a potentially distinct network path that should
also be observed by multiple people, including the sender).
3. Every time I am about to encrypt mail to a key, check the key servers
for that email address, download the key, and make sure it is still the same
4. When downloading a key, GPG could verify that the same email to key mapping
exists on multiple key servers, with each key server authenticated by an
independent TLS key that is stored in the GPG source code or packaging itself.
(Perspectives/notary-style cryptographic multipath authentication).
** The Web of Trust is technically capable of multipath authentication by
itself, but only if you are aware of all of the multiple paths that *should*
exist. Unfortunately, nothing authenticates the whole Web of Trust in its
entirety, so it is impossible to use it to reliably verify that multiple
paths to a key do actually exist and are valid.
tor-talk mailing list - tor-talk[at]lists.torproject.org
To unsusbscribe or change other settings go
----- End forwarded message -----
Eugen* Leitl <a href="http://leitl.org">leitl</a>
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5