PGP/OpenPGP works by combining public key cryptography for key exchange and digital signatures with symmetric encryption for the message itself. The sender encrypts the message with a one-time session key, then encrypts that key for the recipient. Security depends on verifying public keys, protecting private keys and managing trust carefully.
How PGP/OpenPGP actually encrypts and signs messages
PGP/OpenPGP combines public key cryptography and symmetric cryptography so each does the job it is best suited for. The sender creates a random one-time session key, encrypts the message with that key, then encrypts the session key with the recipient’s public key. If signing is used, the sender also applies a digital signature with their private key.
The practical benefit is speed plus trust. Public key operations solve key exchange and identity binding, while symmetric encryption handles the bulk data efficiently. In OpenPGP, the recipient uses their private key to recover the session key, then decrypts the message and can verify the signature against the sender’s public key.
That design is why OpenPGP is still used for email, file encryption and software distribution. It protects confidentiality, but it does not hide metadata such as who you communicated with or when. The cryptography is standardised; the hard part is operating it safely across key verification, revocation and expiry.
Why key verification and trust determine whether it is secure
OpenPGP is only as trustworthy as the public key you choose to use. If an attacker can substitute a malicious public key, they can receive encrypted mail meant for someone else or convince you to trust an impersonated signer. The cryptography can be correct and still fail if key discovery and verification are weak.
That is why fingerprints, out-of-band verification and a disciplined trust model matter more than the encryption algorithm itself. In practice, the user must confirm they have the right key for the right person or system before relying on confidentiality or signatures. Encryption Guide is a useful companion when you want the broader control picture around key custody, envelope encryption and encryption in transit.
PGP signatures add authenticity, integrity and non-repudiation properties only when the signer’s public key is genuinely bound to the signer. If the trust decision is wrong, the signature still verifies mathematically, but it verifies the wrong identity. That is the central operational risk in a web-of-trust model.
What happens to private keys, session keys and message recovery in practice
OpenPGP places the sensitive security burden on the recipient’s private key. Anyone who can use that private key can decrypt protected mail or verify signatures as the owner, so key protection, passphrases and secure storage are critical. The one-time session key is discarded after use, which limits exposure compared with reusing a single symmetric key for every message.
Rotation and revocation also matter. If a private key is lost, copied or suspected of compromise, the associated identity may remain at risk until recipients stop trusting it and move to a replacement key. For long-lived communication channels, this is often a governance problem as much as a cryptography problem, because old keys, old trust decisions and cached public keys can linger.
OpenPGP can recover old encrypted messages only if the recipient still has the relevant private key material. That makes backups and secure archival policy part of the design, not an afterthought. If you need the broader lifecycle view of cryptographic material, NIST SP 800-57 Key Management is the right external reference for cryptoperiods and key lifecycle decisions.
Risk and Threat Considerations
PGP/OpenPGP’s main failure modes are key substitution, private key theft and trust drift over time. The encryption can be strong while the operational model fails, especially when users accept keys by email, skip fingerprint checks or keep old keys in circulation longer than intended.
Failure mechanism: An attacker can impersonate a sender by replacing a public key, or can decrypt protected content after stealing the recipient’s private key or passphrase. Weak revocation handling and stale trust decisions make the compromise last longer.
Impact: Confidential messages can be read, forged signatures can be accepted as authentic, and archived mail can remain exposed if old private keys are compromised. In regulated or high-trust environments, that can turn a single key failure into a prolonged loss of confidentiality and message integrity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | IA-5 — Authenticator Management | OpenPGP depends on protecting and rotating key material over its lifecycle. |
| Recommendation — Manage OpenPGP keys with defined generation, protection, rotation and revocation rules. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | PGP trust depends on binding keys to the right human or system identity. |
| IA-5 — Authenticator Management | Private keys and passphrases function as authenticators that must be controlled across their lifecycle. | |
| Recommendation — Verify key ownership before trusting an OpenPGP public key for confidentiality or signatures. Protect, rotate and revoke OpenPGP key material according to defined lifecycle rules. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | OpenPGP security hinges on safeguarding the private key and related authentication material. |
| Recommendation — Store and handle OpenPGP private keys and passphrases under strict authentication-information controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Private keys and passphrases exposed through poor handling can defeat OpenPGP protection. |
| Recommendation — Prevent leakage of OpenPGP private keys, passphrases and recovery material. | ||
Practitioner Guidance
What to verify: Confirm how users will verify fingerprints, how revocation certificates are stored, and how replacements are published when a key changes. If those steps are not operationalised, the cryptography is only half deployed.
Common mistake: Treating OpenPGP as “set and forget” after key generation. The real control is ongoing key hygiene, including expiry, revocation, private key protection and periodic revalidation of trusted contacts or systems.
Practitioner takeaway: OpenPGP is secure when the crypto, the key lifecycle and the trust process are all treated as one control system, not three separate tasks.