it seems to me that the relaxed gpg key verification that the author uses doesn't give us any more assurances regarding the authenticity of the source than a simple hash offered on the website would. i think in this situation, if the author did not intend to attempt more rigorous verification of the truecrypt pgp key, at least cross-checking that the key offered on the site matches the key offered on a public key server pgp.mit.edu for example would be prudent before signing the truecrypt key with your own.
Import the .asc file in the keyring (File > Import certificates).
Now you should mark the key as trusted: right click on the TrueCrypt Foundation public key
in the list under Imported Certificate tab > Change Owner Trust, and set it as I believe checks are casual.
You should also generate your own key pair to sign this key in order to show you really trust
it and get a nice confirmation when verifying the binary.
i think there are two concerns here. one is that the source is not tainted by a third party during or before the download. the second (arguably much more important in this case) concern is that the compiled binary matches the source. the second concern is addressed well by the author as far as i can tell, but i think that there is room for improvement in their concerns about the former. i assume they have thought about this and do have at least some concerns because it is mentioned that
The PGP signature of the binary can be downloaded
through the button PGP Signature, which makes you
download TrueCrypt Setup 7.1a.exe.sig over HTTPS
(*although with the NSA in the middle, it might not
mean much*).
[emphasis mine]
cross-referencing the pgp signature with at least one other (public) source would go a long way toward allaying those concerns (that the HTTPS might not mean much).
this criticism is in no way meant to detract from the rest of the work, and i mean only to refer to pgp sig verification best practices here.
But you can do this too easily and be make sure yourself! Do it yourself with GPG, then calculate SHA of the binaries, compare with his text. he published the checksums with which he worked in more points of his analysis.
Comments
it seems to me that the relaxed gpg key verification that the author uses doesn't give us any more assurances regarding the authenticity of the source than a simple hash offered on the website would. i think in this situation, if the author did not intend to attempt more rigorous verification of the truecrypt pgp key, at least cross-checking that the key offered on the site matches the key offered on a public key server pgp.mit.edu for example would be prudent before signing the truecrypt key with your own.
You can do yours checks and compare with the author's! It's a very fast thing to do for the checks you mention. The more people repeat it, the better.
i think there are two concerns here. one is that the source is not tainted by a third party during or before the download. the second (arguably much more important in this case) concern is that the compiled binary matches the source. the second concern is addressed well by the author as far as i can tell, but i think that there is room for improvement in their concerns about the former. i assume they have thought about this and do have at least some concerns because it is mentioned that
[emphasis mine]cross-referencing the pgp signature with at least one other (public) source would go a long way toward allaying those concerns (that the HTTPS might not mean much).
this criticism is in no way meant to detract from the rest of the work, and i mean only to refer to pgp sig verification best practices here.
But you can do this too easily and be make sure yourself! Do it yourself with GPG, then calculate SHA of the binaries, compare with his text. he published the checksums with which he worked in more points of his analysis.