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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
