Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 2:19 PM, Peter Lebbing wrote:
> On 17/03/15 22:04, Doug Barton wrote:
>> Assuming you get the package, the signature, and the fingerprint from the same
>> *.gnupg.org resources, what does that buy you?
>
> Assuming they're all protected by https, nothing.

I think you missed my point. If all three resources related to 
verification are provided by the same source, then verifying the 
fingerprint gets you zero added security. It's more or less equivalent 
to using a hash by itself.

> What does verification of that signature buy you though? That your download
> wasn't corrupted?

I covered that later in the message, but basically, yes.

>> If you've somehow downloaded the wrong key by short Id, the signature won't
>> validate. If you have the right key, it will. That's enough to tell the user
>> that the contents of the package are unaltered.
>
> If I were to place something nefarious inside a GnuPG download,

So to start with, that's a pretty big hurdle to jump, and if you have 
access to do that, then you almost certainly have access to do other 
things like changing the fingerprint to verify.

So in my threat model once Eve has access to the site where the 
downloads are posted, it's already game over. You can posit a threat 
model where Eve has access to one thing, but not the other, and that's 
fine; but there are way too many technical and social engineering tricks 
that can be performed if you have access to just the downloads. Your 
idea of "verify the fingerprint from a web page" provides little to no 
improved security in a world where the nefarious actor has no access to 
the downloads in the first place, and zero when they do.

> I'd sign the
> result with a key I created with the short key ID 4F25E3B6.

Why would you bother? Why not just sign it with a completely new key, 
and include in the comments something like "2015 Q1 Signing key for 
official purposes?" That's enough social engineering to "catch" the 
overwhelming majority of users, even the ones sophisticated enough to 
actually review the key that they just downloaded.

> That way, your
> --recv-key command will retrieve both my key and Werners, and the signature will
> happily validate. Creating a short key ID collision is peanuts and can be done
> with off-the-shelf software on a laptop.

... even assuming that this is relevant ...

> This rakes in not just the people who don't check the signature,

when the malicious actor has access to the downloads, those people are 
already hosed, regardless of what extra security you're suggesting.

> but also all
> those who just verify the short key ID. Since it's hardly any effort, I'd do it,
> even though it probably only gains me a few percent coverage.

... and as above, it's totally unnecessary.

>> More extensive checking would be great, but would require a lot of documentation
>> to teach the users how to do it ... are you volunteering to write it? :)
>
> No, but I'm also not telling people they can verify using the short key ID. No
> guidance is better than wrong guidance, IMHO.

In the first place, I disagree with your premise that no guidance is 
better. If for no other reason than providing the "wrong" guidance is 
likely to spur the people with the "right" answer into responding when 
they otherwise would not.

I also disagree with you that I'm providing the wrong guidance. :)

Doug