PGP/GPG verifying authenticity

Question

My boss recently implemented a new security system related to PGP/GPG.

The whole idea behind this is to sign files so that people know from who they came. They don't require us to encrypt them, just verify their authenticity.

The problem is that wrapping my head around such new and complicated concepts is getting harder and harder. We're using GPA Kleopatra.

So what I want to know:

Say I want to send a person a file, I don't know that person, it could be anybody, it doesn't have to be encrypted, and I want him to know it came from me, is there anyway for me to do that?

Again, no encryption, just authenticity verification.

You don't have to explain it to me step by step, a tutorial on some site will do. But keep it simple and straight forward.

Answer 1

While @schroeder's answer addresses the basic process for signature validation, there is an important step missing. The recipient needs to have a copy of your public key, received and/or validated from a trustworthy source, in order to verify your signature. Without a pre-existing trust in your public key, or in a signing authority which has validated your key, validation of the electronic signature is effectively pointless since the key could really belong to anyone.

The most common way this is handled for PGP systems, as @JayFromA pointed out in his comment is via a Web of Trust. An alternative method, typically used in enterprise environments, is Public Key Infrastructure. Both methods are essentially based on the same process though.

1. All clients must be configured to trust the public key(s) of one or more signing authorities.

   • In a Web of Trust, signing authorities can pretty much be anyone whose public key has been received and/or verified from a trustworthy source. The important part here is making sure that the keys you trust to vouch for the authenticity of other keys are themselves authentic, known to be well guarded against abuse, and belonging to users who are sufficiently diligent in verifying ownership of the keys they sign. At some point, this should involve some form of out-of-band communications such as a face-to-face meeting otherwise you've put yourself into a "turtles all the way down" trust model.

   • In a PKI system, one key will be assigned the role of Root Certificate Authority (Root CA) and will probably delegate its signing authority to a select few other CAs by signing their keys. Since this trust is enforced at the enterprise level (or built in to some applications, e.g. web browsers) it's generally very difficult for end-users to personally verify the trustworthiness of the public keys or signing practices of the Root CAs (and, by extension, their delegates). It is also imperative that the Root CA be extremely well guarded, and that the activity of all CAs is regularly monitored for abuse.

2. When a new client is added, their public key must be signed by a trusted signing authority in order to be trusted by existing clients.

   • In a Web of Trust system, the key may be signed by one or more users. Generally, a key's trustworthiness is increased by the number of trustworthy signatures on that key. Of course, trust can be placed in the key directly (and then you may choose to sign it yourself as well) if you have properly verified it out-of-band and you are confident in the user's ability to protect it.

   • In a PKI system, trust in the key is usually established by signature from a delegate CA. The Root CA should never be used, except to establish new delegates or revoke the trust of existing delegates when needed.

3. When any client wants to communicate with another, they must exchange public keys according to the protection intended for the communications. If the communication is to be signed, the recipient will need the sender's public key. If the communication is to be encrypted, the sender will need the recipient's public key. If it is to be both signed and encrypted, both users will need each others' public keys. An important thing to note here is that only public keys should be exchanged - nobody should ever be allowed possession or control of a private key that is not their own.

   • For both Web of Trust and PKI systems, this can be handled via any number of ways. Most commonly, public keys are published to a key server. However, they can also be transferred via e-mail attachment, removable storage, or any other electronic media. It's also quite possible, for some formats, to exchange keys on paper. However, transferring a key reliably from paper back into a computer system is hardly practical.

4. From here, steps 1-3 in @schroeder's answer apply for the signing process. After the message is composed, the sender generates an electronic signature (hash of the message, encrypted with the sender's private key) and attaches it to the message. The rest of this process is essentially handled the same regardless of whether you're using a Web of Trust or PKI.

5. Upon receiving the message, the first step in verifying the signature is to verify the trustworthiness of the key that should have signed it. If a key exchange (step 3 here) hasn't happened previously, the recipient must obtain the sender's public key by some means. Once they've obtained the key, they need to verify the chain of trust for that key. This essentially entails validating that the sender's key has been signed as described in step 2. If the electronic signature(s) on the sender's key cannot be traced back to one or more trusted signing authorities, then the sender's key (and therefore the received message) should not be trusted.

6. After the sender's public key has been verified (and perhaps, depending on the client software's configuration, regardless of it) the recipient will attempt to decrypt the electronic signature with the sender's public key. If decryption fails the message should not be trusted because this means it was signed with a key other than the one known to belong to the sender, and that the recipient will not be able to follow the next step since they don't have the proper key to use for decryption.

7. After the signature has been successfully decrypted, the recipient generates a hash of the message and compares it to the one provided in the signature. Though the specific algorithms used for this may differ, the process is effectively the same for both Web of Trust and PKI systems. If the hash generated by the recipient does not match the one included in the signature, that means the message has been altered in transit and should not be trusted.

8. Depending on the configuration, the recipient's client software will probably display the message to the user along with some indications of the results from the signature analysis. If anything went wrong with the signature verification in steps 6 or 7, or the trustworthiness of the sender's public key could not be verified in step 5, the client software will probably put up some red flags indicating that the user should not trust the origin or integrity of the message. At this point, it's up to the user to decide whether additional validation is needed before actually trusting the message themselves.

All that being said, most people receiving PGP-signed messages - and especially those without proper software to support it - probably just follow the XKCD validation method.

Answer 2

The basic concept behind Digital signatures revolves around a key that only one person (or entity) possesses. That's the 'key' to the authenticity process.

There are different technical methods, but they tend to work in some variation of this:

1. a message is composed
2. a 'hash' (a compressed snapshot) of the message is made
3. the sender's key is used to encrypt the hash

The result is a Digital Signature, which is sent along with the message. The receiver runs the process in reverse on the signature, using the sender's public version of the key (thus proving that the sender sent it), and comparing the sent hash with a hash of the message (thus proving that the message was not changed since it was signed).

There is more to it than that, and the details of the keys can change depending on the type of keys used (symmetric/asymmetric). but that is a quick overview.