GPG / OpenPGP File Encryption Workflow (ASCII Armored)

gpg_file_share_workflow.md

GPG / OpenPGP File Encryption Workflow (ASCII Armored)

Recommended Process for Exchanging Confidential Documents

1. Verify the recipient’s identity using a trusted, independent channel (not email alone).
2. Obtain the recipient’s public key from a trusted source (direct transfer, verified website, or keyserver).
3. Import the recipient’s public key into your local GPG keyring.
4. Verify the recipient’s key fingerprint against a value confirmed via a separate communication channel.
5. Decide whether to mark the key as trusted in your local trust database (this affects GPG behavior, not cryptographic security).
6. Encrypt the file for the recipient and sign it with your private key using ASCII-armored output.
7. Send the resulting .asc file to the recipient over any transport (email, file share, etc.).
8. 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:

• trust
• quit

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 .asc file 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