GPG / OpenPGP File Encryption Workflow (ASCII Armored)
, 475 words, 3 minutes read
Table of contents
- Recommended Process for Exchanging Confidential Documents
- Detailed Workflow
- Key rotation / expiration handling
- Troubleshooting / utility commands
Recommended Process for Exchanging Confidential Documents
- Verify the recipient’s identity using a trusted, independent channel (not email alone).
- Obtain the recipient’s public key from a trusted source (direct transfer, verified website, or keyserver).
- Import the recipient’s public key into your local GPG keyring.
- Verify the recipient’s key fingerprint against a value confirmed via a separate communication channel.
- Decide whether to mark the key as trusted in your local trust database (this affects GPG behavior, not cryptographic security).
- Encrypt the file for the recipient and sign it with your private key using ASCII-armored output.
- Send the resulting
.ascfile to the recipient over any transport (email, file share, etc.). - Recipient decrypts the file with their private key and automatically verifies the signature.
Detailed Workflow
Generate your own keypair (one-time setup)
gpg --full-generate-key
Notes:
- Use a modern key type (defaults are typically appropriate).
- Protect your private key with a strong passphrase.
- Back up your private key securely and separately.
- Never share your private key under any circumstances.
Export and share your public key
gpg --armor --export your@email.com > my-public-key.asc
Notes:
- Public keys are designed to be shared openly.
- You can distribute via email, website, or keyservers.
- This does not expose your private key.
Obtain recipient public key
Possible sources:
- Direct file from recipient
- Their official website
- Keyserver lookup
Notes:
- Do not proceed with encryption until you have a key you intend to verify.
- Treat all unverified keys as potentially malicious (key substitution / MITM risk).
Import recipient public key
gpg --import recipient-public-key.asc
Notes:
- Adds the key to your local keyring.
- Importing alone does NOT establish trust.
Verify fingerprint
gpg --fingerprint recipient@example.com
Notes:
- Must be verified via a separate trusted channel (call, Signal, in-person, etc.).
- This is the critical step that prevents man-in-the-middle attacks.
- Never treat an unverified key as valid even if it was imported successfully.
(Optional) Set trust level
gpg --edit-key recipient@example.com
Then:
trustquit
Notes:
- Trust level affects GPG’s UI warnings and keychain behavior.
- It does NOT affect cryptographic correctness—only local policy decisions.
- Safe to skip if you directly specify recipients during encryption.
Encrypt and sign the file (recommended)
gpg --armor --sign --encrypt \
--recipient recipient@example.com \
document.pdf
Notes:
- Encryption ensures only the recipient can read the content.
- Signing proves authorship and ensures integrity (detects tampering).
- ASCII armor makes output safe for email and text-based transport.
- Signing is strongly recommended; encryption alone provides confidentiality but not authenticity.
Send encrypted file
Notes:
- Send the
.ascfile via email or file transfer. - No shared password or secret exchange is required.
Recipient decrypts and verifies
gpg --decrypt document.pdf.asc > document.pdf
Notes:
- Requires recipient’s private key.
- Signature verification happens automatically during decryption.
- Recipient will see whether the signature is valid and trusted.
Key rotation / expiration handling
Notes:
- Always re-verify fingerprints if a key changes or is replaced.
- Expired or replaced keys should never be assumed to represent the same identity without re-verification.
- Treat new keys as untrusted until explicitly validated.
Troubleshooting / utility commands
gpg --list-keys
gpg --list-secret-keys
gpg --fingerprint