GPG is not just for sending encrypted emails; it’s a powerful tool for verifying the integrity and authenticity of any file on your Linux system.
Let’s say you have a configuration file, my_app.conf, that you want to ensure nobody tampers with, and you want to prove you created it.
First, you need a GPG key pair. If you don’t have one, generate it:
gpg --full-generate-key
Follow the prompts. Choose RSA and RSA, set a key size (4096 bits is good), and pick an expiration date (or none). The most important part is the passphrase – make it strong. This key pair consists of your private key (which you keep secret) and your public key (which you can share).
To encrypt my_app.conf for yourself, you’ll use your own public key:
gpg --encrypt --recipient your_email@example.com --output my_app.conf.gpg my_app.conf
Replace your_email@example.com with the identifier associated with your GPG key. This creates my_app.conf.gpg. If someone intercepts this file, they can’t read it without your private key and passphrase.
To decrypt it:
gpg --decrypt --output my_app.conf my_app.conf.gpg
You’ll be prompted for your passphrase.
Now, for signing. Signing creates a separate file that proves the file’s origin and integrity.
gpg --armor --detach-sign my_app.conf
This creates my_app.conf.asc. The --armor flag makes it ASCII-armored, which is easier to share and paste into text. This signature file contains a cryptographic hash of my_app.conf and is signed with your private key.
To verify the signature:
gpg --verify my_app.conf.asc my_app.conf
If the signature is valid, GPG will tell you "Good signature from Your Name your_email@example.com". If the file my_app.conf was modified after signing, or if the my_app.conf.asc file was altered, verification will fail.
You can also sign and encrypt in one go, creating a self-contained, encrypted, and signed package.
gpg --encrypt --sign --recipient your_email@example.com --output my_app.conf.signed.gpg my_app.conf
This is useful when you want to send a file to someone, ensuring only they can read it, and they can verify it came from you.
To verify and decrypt this combined file:
gpg --decrypt --output my_app.conf my_app.conf.signed.gpg
After entering your passphrase, GPG will verify the signature before decrypting. If the signature is bad, it won’t decrypt.
The real magic happens when you need to delegate trust or verify files from external sources. You can import public keys from others. For example, to import a public key from a file named other_person.gpg:
gpg --import other_person.gpg
Once imported, you can verify their signatures. However, GPG doesn’t automatically trust that the imported public key truly belongs to that person. You need to "sign" their public key with your own private key to indicate you’ve verified their identity (e.g., met them in person, checked their website, etc.).
gpg --sign-key other_email@example.com
This is the "Web of Trust" model. You’re essentially saying, "I, as a trusted entity, vouch for this key belonging to this person." The more people who sign a key, the more trust GPG can place in it.
When GPG verifies a signature, it checks not only the cryptographic integrity but also the trust you’ve established for the signing key. If you haven’t explicitly trusted a key, you might see warnings about "untrusted" signatures, even if the crypto check passes.
The process of verifying a signature involves GPG calculating a hash of the file and comparing it to the hash embedded within the signature. If they match, the data hasn’t changed. Then, it uses the public key associated with the signature to decrypt the signature itself, revealing the identity of the signer. Finally, it checks your local trust database to see if you trust that signer’s key.
If you ever need to revoke a key (e.g., you lost your private key or it was compromised), you generate a revocation certificate while you still have access to your private key:
gpg --output revoke.asc --gen-revoke your_email@example.com
You should store this revoke.asc file securely offline. If you lose your private key, you can upload this certificate to a keyserver to inform others that your key is no longer valid.
The next hurdle is understanding how to manage multiple keys and their trust levels effectively, especially in team environments.