>>> Assuming a MITM it's already game over here, the MITM doesn't even >>> have to control one of the CAs. >> >> No. If you are verifying the GPG signature it is not game over. It >> doesn't matter how you retrieve the signature and the signed file if >> you verify them, this is assuming that the crypto primitives aren't >> broken. > > Unless I misunderstood something all you are verifying is that the > attacker's GPG signature matches the attacker's archive. This just > gives you a false sense of security.
It doesn't really matter if the wrong signature and archive match since you don't even have the attackers key. >>> There is also an alternative verification method: `gpg --keyserver >>> keys.gnupg.net --recv-keys 3D9AEBB5`. Assuming a MITM, >>> keys.gnupg.net is accessed in clear. And generating a GPG key with >>> the same key ID is trivial. So game over again. >> >> This is true. Retrieving the key is not a trivial problem. This is >> why projects should start printing their fingerprint on all >> promotional material and on every website and on every talk they >> give. This way it is easier to verify that you have the right key. >> For example some people who give talks at defcon or CCC have their >> fingerprints on the first or last or in some cases every slide. >> > > I agree. For GPG to be implemented properly, the key must be > distributed separately from the content. The goal is to make the > attack more expensive by forcing the attacker to compromise multiple > communication channels. And the key fingerprint must be in the long > form to mitigate potential collision attacks. 7B29 6212 4A73 E1E9 15E8 A7D4 7F96 C964 9CBC BF51 <- This is a fingerprint 9CBCBF51 <- This is just a short id _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev