Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 2:56 PM, Peter Lebbing wrote:
> On 17/03/15 22:34, Doug Barton wrote:
>>> 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.
>
> No, I think that's what I mean as well. If they all come from the same source,
> it gets you nothing to check the signature. So I don't see why you would verify
> the signature at all.

Because it tells you that the package was not tampered with. I've 
covered this several times now.

>> 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.
>
> By creating a short key ID collision, I'm also getting those people that read
> your e-mail or a similar thing somewhere on the web, and just download the short
> key ID. I'm also getting those people that get a "BAD signature" and then do a
> new --recv-key with the short key ID in an unfortunate attempt to get it to
> verify ("hmmm, maybe it has expired?").

Again, I think you're missing the bigger picture here. If you have write 
access to the FTP site, why would you even bother creating the signature 
for your malicious package with a key that has the same short key Id?

You're trying to defend against an incredibly unlikely threat model. If 
I download 'malicious package' + 'signature for malicious package 
created by key controlled by malicious actor,' one of two things is 
overwhelmingly likely to happen:

1. I blindly import the key, verify the signature, and move on; or
2. I import the key, perform a cursory review, verify the signature, and 
move on.

Either way, your short key Id collision is out of spec. The user in this 
situation has no way to know that there should be a short key Id other 
than the one that is related to the signature that they have in hand. 
Since both the package and the signature are under Eve's control, the 
threat model you are suggesting is a complete red herring.

> But back to my primary objection:
>
> I consider it bad advice to tell someone to rely on the short key ID. Sounds
> like a bad habit potentially getting bootstrapped to me.
>
> That's really all this is about.

Thank you for confirming your real motives. :) I understand in theory 
that relying solely on the short key Id is not a good practice in a 
situation where you want things to be "very secure." But we do indeed 
have a bootstrapping issue here, which is, "Where do you start when it 
comes to rank beginners?" I think you are asking way too much, and 
giving near-zero value in return.

> You could also say they should check the sha1sum, like Clark ended up doing. Or
> typing
>
> gpg --fingerprint -k 4F25E3B6
>
> and checking it says
>
> pub   2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
>        Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
> uid       [  full  ] Werner Koch (dist sig)
> sub   2048R/AC87C71A 2011-01-12 [expires: 2019-12-31]
>
> with a little caveat that you should actually get the fingerprint from somewhere
> trusted, not from a stranger.

Sure, but now you've entered a very sticky briar patch, with a lot of 
bootstrapping knowledge that is not easy for a rank beginner to grasp. 
You and I "get" what you're talking about, but that knowledge came from 
experience. (and again, the extra security that you get is of very 
limited value at this stage of the game)

Doug