[Nix-dev] [yui at cock.li: Re: Malicious installation methods]

[Yui Hirasawa]

>>> 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