Validating GPG key signature authenticity

The usual means of verification is to contact the key owner and ask him/her to provide you (over the phone, or in person) with their key fingerprint. If you have strong reason to believe you are actually speaking to the person identified by the key, AND if the fingerprint the person provides matches the fingerprint of the key you have, THEN you can be quite certain you have the owner's real public key (and NOT a counterfeit key, created by an imposter for the purpose of impersonating that person).

Once you have verified the authenticity of the key to your satisfaction, you should sign that public key with your own private key. Once you've signed the key, you will no longer get those WARNINGs, because by signing it, you have indicated that you believe the key to be authentic.

There are two distinct purposes for file verification:

1. A. to protect against accidental corruption during downloading

2. to protect against a MITM-attack, or even webserver compromise if the private pgp key has not been compromised.

For A, a hashing function like SHA-1, MD5, ... is more than satisfactory. However it would do no harm to use a more modern hash that is still considered cryptographic.

For B, things get seriously more complicated. For starters you should be doing all communications by correctly certified HTTPS (SSL):

https://httpd.apache.org/download.cgi#verify
https://httpd.apache.org/dev/verification.html#Validating
https://www.apache.org/dist/httpd/KEYS

You're in luck, apache does provide such access to their website.

Now lets make an assessment of what risks remain and what risks have been mitigated. A simple MITM-attack is no longer possible. To still execute a MITM-attack an attacker could however:

1. Obtain a certificate for this website from a Certificate Authority by:

   • tricking them into believing that they own this website and paying them.
   • tricking browsers in accepting them as a CA (note that several governments are included in browsers as CA, and that existing CA's can delegate the trust they receive to third parties without any notification, see the etisalat incident) If this then comes to light that this subCA does some bad shit, and the CA refuses to revoke this subCA then there is still all the websites that are legitimately certified by the CA, which causes a pressure on browsers to keep trusting the CA.
   • by breaking in and stealing the private key of the CA
   • by forcing them by law to make such a certificate (subpoena)

2. Steal the private key of the server sending the data.

Wow, that might not be perfect, but imagine having to do something like that. I bet your geek baby brother upstairs doesn't often come round to that. It considerably raises the bar for an attacker.

Further, if an attacker could just compromise the server of the website, they could just change the file as well as the md5, sha1 or other hashes as well as the pgp keys it serves, and therefore wouldn't have to do a MITM-attack. This last option is by far the preferred as it is often simpler to get into a server than to get a certificate.

Note that sometimes the hashes and downloaded files are not served from the same location. In itself that is good. It would complicate the work of an attacker. So, say I have a https certified website and you offer some files for download. I might offer to put the hashes of those files on my website to help you out. Or in case of apache, the actual downloads are on mirrors which do not have https.

Now the hashes are the crucial link in the verification. Note that MD5 has been broken and that SHA1 is on its way. It is bad from apache to still provide these for security purposes. If all else fails and both of them are available, check them both. A collision attack to yield both the same md5 and sha1 values for two file has not yet been discovered as far as I know.

What if https is not available for the given site. Well, a file served to you from that server is just as safe as a hash on the website (if it is on the same server), or a pgp key, or anything else for that matter.

Beyond https:

If https does not satisfy your need for security (and really it shouldn't) or https was not available for the website, what can you do?

Using a pgp key to verify signatures might allow you to verify the files if you can get a legitimate public key from the signer. PGP uses a system called Web of Trust in order to verify its keys, as opposed to the central Certificate Authorities used in HTTPS.

When you include a pgp key in your keyring it is not necessarily known if this key really belongs to the user id that comes with it. To be able to verify that, users sign each others keys after verifying each other's identity, for example by meeting in person or calling that person. Further it is possible to construct a chain between you and say the apache signing key if you haven't verified them in person but someone you met did, or they met someone who did...

Thus, when a new key enters your keyring, and none of the other keys in your keyring that are already verified have signed this key and you try to use it, gpg or pgp will issue a warning, just like browsers give you a warning if you surf to an https website who's certificate can not be verified.

Apart from signing the key yourself to verify that it is legitimate the software might automatically accept it as valid if one of your fully trusted contacts signed it, or 3 marginally trusted contacts signed it... That is implementation/user dependant. Just as your browser will silently accept any SSL certificate if it is signed by a CA that is known to be trusted (by your browser that is).

What does this all mean in practice? Well, if you are in the middle of the geek-knows-geek world, this probably gives you a reasonable protection. For the rest of the world, it is more like a monstertruck without petrol.

For ordinary people pgp and the web of trust have some considerable problems:

• improper use of gpg and web of trust breaks its security
• proper use of it is difficult, complicated and free tools like gnupg and it's frontends are shaggy
• if you or the other side are not well anchored in the web of trust, verifying keys is next to impossible
• a chain of trust really means you have to trust all the people in between. The longer it gets the less safe. If say all your links to the apache signing key pass through the same persons that might set up a MITM-attack, than pgp only serves as a false sense of security.
• Web of Trust helps authorities to draw a map of your social network just like facebook.

It does however not suffer from some of the limitations of https, like it is not possible with pgp to convince one company to take your money and give you a certificate that will fool the entire world. On the other hand, it is considerably less usable for the general public. It illustrates how simplicity is a key determinant for security.

In conclusion it is important to realize that HTTPS and PGP are not mutually exclusive. No one prevents you from trying to use both to the best of your ability. What one should realize is that any chains of security are only as strong as the weakest link. Say a pgp key downloaded through https has the weaknesses of pgp and the weaknesses of https. Every link in a chain adds its weaknesses to the result.

I will keep adding interesting links to this answer as I discover them.

See also:

• Https everywhere Firefox plugin that will make your browser redirect you to https on a number of well known sites.
• Perspective - a firefox plugin that allows asking computers around the world to verify they get the same HTTPS certificate for a website as you do. Note that the traffic between you and these "notaries" is signed but not encrypted. You are thus openly notifying those and potential eavesdroppers what sites you are browsing to.
• How to Deploy HTTPS Correctly
• Law Enforcement Appliance Subverts SSL
• Certied Lies: Detecting and Defeating Government Interception Attacks Against SSL