How to find and verify a trust path?

[Philip Jägenstedt]

On Mon, Sep 16, 2013 at 8:11 PM, Peter Lebbing <peter at digitalbrains.com> wrote:
> On 16/09/13 17:45, Philip Jägenstedt wrote:

>> I'm guessing key servers simply can't be queried for this information.
>
> I'm pretty sure they can't be directly queried for this information.

Too bad. I guess one could do it by starting at the destination and
following signatures back using a shortest path algorithm and a lot of
requests to the keyserver, though.

>> If there are no good tools, what have others done to verify that they have a
>> path to 4F25E3B6?
>
> Most of them probably did nothing, since it's useless other than for statistical
> fun. There is nothing to be gained from knowing one or more paths.
>
> Any "attacker" doesn't need to do much effort to create so many paths to that
> key it dwarves any other key by comparison. Is the validity of that key then
> somehow increased, because it has so many paths?

How would an attacker create n independent paths without deceiving n people?

<http://www.gnupg.org/gph/en/manual.html#AEN385> says:

"At one extreme you may insist on multiple, short paths from your key
to another key K in order to trust it. On the other hand, you may be
satisfied with longer paths and perhaps as little as one path from
your key to the other key K. Requiring multiple, short paths is a
strong guarantee that K belongs to whom your think it does. The price,
of course, is that it is more difficult to validate keys since you
must personally sign more keys than if you accepted fewer and longer
paths."

Having multiple, short paths to a key would increase my confidence,
even if it's not as good as face-to-face verification. When I'm about
to compile some software and install it on a public server, that's
useful to me. Am I doing it wrong?

-- 
Philip Jägenstedt