Type “PGP vs GPG” into a search bar and you will find a decade of confused forum threads arguing about which one is “better.” The honest answer is that they are not really competitors. PGP is the brand name Phil Zimmermann gave his encryption software in 1991. OpenPGP is the open standard that grew out of it. GPG, short for GNU Privacy Guard, is the free software that implements that standard and is the tool almost everyone actually runs today. Understanding the difference matters if you sign Git commits, encrypt email, verify a Linux package, or evaluate a commercial encryption product for your company. This comparison breaks down the history, the current algorithms, real benchmark numbers, pricing, and where each option actually gets used in production in 2026.
PGP vs GPG: The Short Answer
PGP is a product lineage. GPG is a free implementation of the OpenPGP standard that PGP itself popularized. When someone asks whether to use “PGP or GPG,” they are usually really asking whether to pay for a commercial encryption suite from Broadcom (which now owns the old Symantec PGP product line) or to use GnuPG, the free tool maintained by the GnuPG project and bundled into tools like Gpg4win and GPG Suite. Both speak the same OpenPGP format, defined most recently in RFC 9580, so a file encrypted with one can usually be opened with the other, provided both sides support the same algorithm choices.
For the vast majority of developers, sysadmins, and security teams, GPG is the default choice because it costs nothing, runs on every major operating system, and gets updated on a public schedule. Commercial PGP products still matter in regulated industries that need a vendor contract, dedicated support line, and centralized key management console. The rest of this article walks through exactly why, with the current version numbers, algorithm defaults, and benchmark figures to back it up.
What Is PGP? From Phil Zimmermann to Broadcom
Phil Zimmermann released Pretty Good Privacy in 1991 as a way for ordinary people to encrypt email and files without needing a government-approved key escrow system. The software spread quickly, in part because it was exported internationally against the wishes of U.S. export-control regulators at the time, which turned Zimmermann into something of a free-speech cause celebre in the crypto community. The name “PGP” originally referred to that specific piece of software and later to the company Zimmermann helped found around it.
The Symantec and Broadcom Years
PGP Corporation built a commercial business around encryption products through the 2000s before Symantec acquired the company in 2010. Symantec folded PGP into its enterprise encryption lineup, selling products like PGP Encryption Desktop and PGP Command Line to businesses that needed centralized key management, audit trails, and a support contract. When Broadcom acquired Symantec’s enterprise security business in 2019, those PGP-branded products came along with it. Today, “PGP” as a commercial product family lives inside Broadcom’s enterprise security portfolio, aimed at large organizations rather than individual users.
That history explains a lot of the confusion. PGP the brand is now a Broadcom product. PGP the data format evolved into the vendor-neutral OpenPGP standard. And GPG is the free software most people actually touch when they type a command like gpg --encrypt. None of this is a knock on the original software. It simply means the word “PGP” now points to at least three different things depending on context, and getting that straight is the first step in any real comparison.
It also explains why so many search results and forum answers talk past each other. A sysadmin asking how to verify a signed package is almost always dealing with GPG, since that is what Linux distributions, Git, and most open-source tooling actually run. A procurement manager evaluating “PGP” for a healthcare company is almost always looking at a Broadcom enterprise quote, a support contract, and a key management console, not a command-line tool. Both people are technically talking about the same underlying cryptography, but they are shopping in two completely different markets.
What Is OpenPGP, and Why It Matters More Than Either Brand Name
OpenPGP is the actual technical standard that makes PGP and GPG compatible with each other. It started as RFC 2440 in 1998, was superseded by RFC 4880 in 2007, and the current base specification is RFC 9580, published by the IETF in July 2024. Each revision added support for newer algorithms while trying to preserve backward compatibility with older messages and keys.
RFC 9580 is a meaningful jump because it bakes modern elliptic-curve cryptography into the required algorithm set instead of treating it as optional. The specification requires implementations to support X25519 for encryption, Ed25519 for digital signatures, SHA-256 for hashing, and AES-128 for symmetric encryption, while also defining optional algorithms like Ed448, X448, and AES-256 for higher security margins. That is a notable shift from the RSA-centric defaults that dominated PGP’s early decades.
One subtlety worth flagging for engineers building OpenPGP tooling: RFC 9580 assigns new, distinct algorithm identifiers to Ed25519 and X25519 that are not byte-for-byte interchangeable with the legacy Curve25519 and Ed25519 encodings used by older OpenPGP implementations. If you are integrating two different OpenPGP libraries, check which encoding each one emits before assuming automatic interoperability. A key generated as “modern” Ed25519 in one tool is not guaranteed to be read correctly by a tool that only understands the older encoding.
What Is GPG (GnuPG)? The Free Implementation Almost Everyone Runs
GNU Privacy Guard, almost always shortened to GPG or GnuPG, is a free software implementation of the OpenPGP standard released under the GNU General Public License. It was created as part of the GNU project specifically so that strong encryption would not depend on a single commercial vendor or a patent-encumbered algorithm. Because it costs nothing and ships in nearly every Linux distribution’s package manager, GnuPG became the default way most developers, sysadmins, and open-source projects actually touch OpenPGP.
GnuPG development continues at a steady clip. Current release notes point to GnuPG 2.5.24, released in September 2026, carrying partial support for the newer RFC 9580 and RFC 9980 specifications. Windows users typically get GnuPG through Gpg4win, a bundle that packages GnuPG together with the Kleopatra graphical key manager; Gpg4win 5.1.1 became available on September 23, 2026, while an earlier Gpg4win 5.0.0 release bundled GnuPG 2.5.16. macOS users commonly reach the same underlying GnuPG engine through GPG Suite or Homebrew.
GnuPG supports the full modern OpenPGP algorithm set: RSA for compatibility with older keys, Curve25519-family encryption and Ed25519-family signatures for new keys, AES at 128, 192, and 256 bits, plus legacy ciphers like Camellia and Twofish for specific compatibility needs. It also still supports DSA and ElGamal, though those are considered legacy choices that new key generation should avoid.
PGP vs GPG: Full Specs and Feature Comparison
The table below lines up a typical commercial PGP deployment, Broadcom’s Encryption Desktop and Command Line product family, against GnuPG, the free OpenPGP implementation. Both ultimately speak the same wire format, so the real differences show up in support model, platform reach, and enterprise tooling rather than raw cryptographic capability.
| Feature | Commercial PGP (Broadcom/Symantec) | GPG (GnuPG) |
|---|---|---|
| Underlying standard | OpenPGP (RFC 9580) | OpenPGP (RFC 9580) |
| Source code | Closed, proprietary | Fully open source, GNU GPL |
| License cost | Quote-based enterprise licensing, per seat | Free, $0 |
| Current core version | Not publicly versioned the same way; enterprise release cadence | GnuPG 2.5.24 (Sept. 2026) |
| Signature algorithms | RSA, ECC-based signatures depending on product configuration | RSA, Ed25519, Ed448, legacy DSA |
| Encryption algorithms | RSA, ECC depending on configuration | RSA, X25519, X448, legacy ElGamal |
| Symmetric ciphers | AES (bit length varies by product build) | AES-128/192/256, Camellia, Twofish |
| Hash support | SHA-2 family in most current builds | SHA-2 family broadly; SHA-3 and RFC 9580 mappings depend on installed version |
| Smartcard/HSM support | Yes, enterprise key management modules | Yes, via GnuPG smartcard daemon and OpenPGP card standard |
| Key server / WKD support | Enterprise key management server, separate product | Yes, Web Key Directory and standard keyservers built in |
| Centralized key escrow/recovery | Yes, built for enterprise compliance | Not built in; requires separate tooling or policy |
| Vendor support/SLA | Yes, paid support contract | Community support, paid third-party support optional |
| GUI front-ends | Bundled enterprise console | Kleopatra, GPG Suite, Mailvelope, Enigmail-successor plugins |
| Primary audience | Regulated enterprises needing audit trails | Developers, sysadmins, individuals, open-source projects |
Notice that the cryptographic ceiling is nearly identical in both columns. Any gap you actually feel day to day comes from licensing, support, and management tooling, not from one side having “better encryption” than the other.
Smartcard support deserves a specific callout because it is often the deciding factor for security teams. GnuPG’s smartcard daemon talks directly to the OpenPGP card standard, so a YubiKey or a Nitrokey can hold the private key material and perform signing operations without ever exposing the key to the host computer’s memory. Commercial PGP products offer similar hardware-token integration through their own enterprise modules, but the setup usually runs through the vendor’s management console rather than a handful of command-line flags. If your team already standardizes on hardware security keys for other purposes, that existing investment tends to carry over cleanly to whichever OpenPGP tool you choose.
Which Algorithms Each One Supports in 2026
For new OpenPGP keys generated in 2026, the practical guidance from the GnuPG project and the RFC 9580 authors converges on a simple recommendation: use an Ed25519 signing key paired with an X25519 encryption subkey. That combination gives you compact keys, fast operations, and alignment with the newest version of the standard. RSA has not disappeared and is not broken, but it is now the compatibility option rather than the default for fresh keys.
Key Size Recommendations for New Keys
- Ed25519 + X25519: the modern default when every recipient and tool in your workflow supports the current RFC 9580 encoding.
- RSA-3072 or RSA-4096: still the right call when you need compatibility with older OpenPGP clients, hardware security tokens, or enterprise products that have not caught up to the newer curve encodings.
- DSA, ElGamal, SHA-1 signatures, and obsolete cipher suites: treat as migration targets, not defaults, for any key created or renewed in 2026.
RSA-4096 is not automatically “more secure” than RSA-3072 or Ed25519 in a way that matters for most threat models. In practice, how you protect the private key, whether you set a sane expiration date, and how quickly you can revoke a compromised key tend to matter more than the raw bit length. A perfectly generated RSA-4096 key sitting unprotected on a laptop is less secure than a modest Ed25519 key stored on a hardware token.
One operational detail that trips people up: confirm whether your specific GnuPG build, Gpg4win release, or commercial PGP client actually emits the newer RFC 9580-native Ed25519 and X25519 identifiers, or whether it is still writing the older legacy Curve25519/Ed25519 encoding. The two are not guaranteed to be byte-for-byte interchangeable across every implementation, so mixed environments with multiple vendors should test interoperability before standardizing on curve keys for everyone.
Benchmarks: How Fast Is RSA vs Modern Curve Cryptography in Practice
Both PGP and GPG rely on the same underlying mathematics, so the real performance question is RSA versus elliptic-curve cryptography rather than PGP versus GPG as products. Published OpenSSL benchmark figures give a useful, if hardware-dependent, picture of the gap.
| Algorithm and operation | Throughput | Source |
|---|---|---|
| RSA-2048 signing | 1,612.2 ops/sec | MojoAuth, OpenSSL 3.6 benchmark |
| RSA-2048 verification | 63,608.5 ops/sec | MojoAuth, OpenSSL 3.6 benchmark |
| RSA-4096 signing | 275.4 ops/sec | MojoAuth, OpenSSL 3.6 benchmark |
| RSA-4096 verification | 18,786.9 ops/sec | MojoAuth, OpenSSL 3.6 benchmark |
| RSA-2048 signing (separate test rig) | roughly 1,000 ops/sec | OpenSSL Cookbook, Feistyduck |
| RSA-2048 verification (separate test rig) | roughly 22,000 ops/sec | OpenSSL Cookbook, Feistyduck |
| ECDSA P-256 signing (same test rig) | roughly 10x the RSA-2048 signing rate | OpenSSL Cookbook, Feistyduck |
| ECDSA P-256 verification (same test rig) | roughly 6,500 ops/sec | OpenSSL Cookbook, Feistyduck |
Two patterns hold up across both benchmark sources. First, RSA-4096 signing is dramatically slower than RSA-2048 signing on the same hardware, roughly 5.9 times slower according to the MojoAuth benchmark run on OpenSSL 3.6, because RSA private-key operations scale poorly with modulus size. Second, elliptic-curve signing consistently beats RSA signing by a wide margin on the same test rig, which is why RFC 9580 made X25519 and Ed25519 the required baseline instead of an optional extra. The OpenSSL Cookbook’s performance chapter, maintained by Feistyduck, documents the same RSA-versus-ECDSA pattern using the standard openssl speed benchmarking tool that OpenSSL’s own project documentation describes for reproducing these numbers on your own hardware.
Treat every number in that table as illustrative rather than a universal constant. CPU instruction sets, whether AES-NI and related acceleration are available, OpenSSL version, and message size all shift the exact figures. What does not change across tested environments is the direction of the gap: curve-based signing is consistently faster than RSA signing at comparable security strength, while RSA verification remains competitive or faster in some configurations because RSA’s public exponent is typically small.
Pricing: Free GPG vs Quote-Based Commercial PGP
Cost is where the PGP-versus-GPG decision becomes concrete for a budget conversation. GnuPG itself, along with its most common front-ends, carries no license fee because it ships under the GNU GPL. Commercial PGP products from Broadcom, by contrast, follow the same enterprise-software pattern as most Broadcom-owned Symantec products: quote-based licensing tied to seat count, support tier, and deployment scale, with no public retail price list.
| Product | Type | Pricing model | Platform |
|---|---|---|---|
| GnuPG (GPG) | Free OpenPGP implementation | $0, GNU GPL | Linux, Windows, macOS |
| Gpg4win 5.1.1 | Free Windows bundle (GnuPG + Kleopatra) | $0, GPL | Windows |
| Kleopatra | Free GUI key manager | $0 | Windows, KDE Linux |
| GPG Suite / GPGTools | macOS front-end for GnuPG | Free tier; paid tier for extended support | macOS |
| Broadcom/Symantec PGP Encryption Desktop | Commercial enterprise suite | Quote-based, per seat | Windows, macOS |
| Broadcom/Symantec PGP Command Line | Commercial server/automation tool | Quote-based licensing | Linux, Windows, Unix |
| Mailvelope | Free browser extension for webmail OpenPGP | $0 | Chrome, Firefox |
| Proton Mail | Hosted email with native and OpenPGP-interoperable encryption | Paid service plans (not per-key licensing) | Web, mobile, desktop |
The practical upshot: an individual developer or a small team has almost no financial reason to buy a commercial PGP license. GnuPG, Gpg4win, Kleopatra, GPG Suite, and Mailvelope cover encryption, signing, key management, and browser-based webmail encryption without a single invoice. Commercial PGP earns its quote-based price tag in organizations that specifically need centralized key escrow, compliance reporting, and a support contract they can point to during an audit, not because the underlying cryptography is stronger.
Real-World Examples: Where PGP and GPG Actually Run Today
It helps to see where OpenPGP tooling actually shows up in production rather than just in theory. These six examples cover the bulk of real deployments in 2026.
- Debian and Ubuntu package signing: both distributions rely on GPG to sign APT repository metadata, so every
apt updateon a Debian-based system quietly verifies a GPG signature before trusting a package list. - Git commit and tag signing: developers who want a verified “Verified” badge on GitHub or GitLab commits typically sign with a GPG key, linking a Git identity to a cryptographic key rather than just a name and email string anyone could type.
- SecureDrop: the open-source whistleblower submission platform used by newsrooms relies on GPG to encrypt documents between sources and journalists, specifically because it is auditable, free, and does not require trusting a single commercial vendor.
- Qubes OS Split GPG: this security-focused operating system isolates the GPG private key inside a dedicated virtual machine, so a compromised browser or email client in another VM never has direct access to the signing key.
- Proton Mail and Mailvelope: Proton Mail supports OpenPGP-compatible workflows for exchanging encrypted mail with non-Proton users, while the Mailvelope browser extension adds the same OpenPGP capability directly to Gmail or other webmail interfaces.
- Regulated enterprise deployments: banks, insurers, and healthcare organizations that need a signed support contract and centralized key management console are the core customer base still buying Broadcom’s commercial PGP Encryption Desktop and Command Line products.
Notice the pattern. Everywhere that needs speed, transparency, and zero licensing friction, from Linux package signing to journalist source protection, GPG is the tool actually running. Commercial PGP survives specifically in environments where a procurement department needs a vendor to call, not because GPG lacks a capability.
Web of Trust vs Enterprise PKI: How Each Side Verifies Identity
Encryption only matters if you actually know whose key you are using, and this is where GPG and commercial PGP diverge the most in daily practice. GnuPG was built around the Web of Trust model, where individual users sign each other’s keys to vouch for identity, and trust accumulates organically through a decentralized network of personal signatures. There is no central authority deciding whether a key belongs to the person it claims to represent. Instead, you decide how much you trust a key based on who else has signed it and how much you trust those signers in turn.
That model works well for open-source communities, where maintainers meet at conferences and do in-person key-signing sessions, but it scales poorly inside a 10,000-person company that needs a predictable, auditable answer to “who approved this key.” Commercial PGP products solve that problem the way enterprise software usually does: with a centralized key management server that issues, tracks, and can revoke keys from a single console, backed by the same kind of organizational hierarchy a company already uses for Active Directory or an internal certificate authority. An IT administrator can see every active key, enforce expiration policies, and pull audit logs for a compliance review without relying on informal trust signatures built up over years.
Neither model is strictly better. The Web of Trust is resilient precisely because it has no single point of failure or control, which matters enormously for journalists, dissidents, and open-source maintainers who cannot and should not depend on a corporate key server staying online or staying neutral. Centralized key management is better for a bank that needs to prove to a regulator exactly who had access to a signing key on a given date, and who approved revoking it when an employee left the company. Choosing between PGP and GPG is, in part, choosing which trust model actually fits how your organization already operates.
Security Track Record: Vulnerabilities and Patches in 2025-2026
No encryption tool is immune to implementation bugs, and both GnuPG and the software bundled around it have had their share of fixes. The important distinction is between a flaw in the OpenPGP specification itself, which would be catastrophic, and a flaw in a specific piece of bundled software, which is routine and gets patched like any other application.
The Gpg4win change history documents exactly this kind of routine fix. Gpg4win 5.1.1 updated the bundled libpng library to close CVE-2026-25646, a vulnerability that could be triggered through the bundled software when a user opens mail through Kleopatra. The earlier Gpg4win 5.0.0 release separately documented a fix for a GnuPG issue involving how third-party key signatures were handled, plus a memory-access violation bug. Both are implementation issues in bundled components, not evidence that the OpenPGP format or GnuPG’s core cryptography is broken.
This is exactly the kind of patch cadence you want to see from an actively maintained open-source project: a public changelog, a tracked CVE, and a fixed release within the same version cycle. Commercial PGP vendors patch their products too, but because the release notes are not published with the same level of public detail, it is harder for an outside security researcher to track exactly when and how a given issue was resolved. That transparency gap, more than any difference in cryptographic strength, is a real factor worth weighing when you choose between the two.
What GnuPG’s Own Developers Say About the Standard
It helps to hear the standard-versus-implementation distinction directly from people who build this software for a living, rather than from marketing copy on either side.
Software developer Lars Wirzenius put it plainly in a talk introducing both technologies: “OpenPGP is the prevalent standard for cryptography for secure software distribution and GnuPG is its prevalent Open Source implementation,” framing exactly the relationship this article has been describing in a talk later posted on YouTube.
Neal H. Walfield, who has worked on both GnuPG and the newer Sequoia PGP project, makes the same point in more technical language in his advanced introduction to GnuPG: “GnuPG is an implementation of OpenPGP, an encryption standard published by the Internet Engineering Task Force (IETF).” That is as clean a definition of the PGP-versus-GPG relationship as you will find anywhere.
GnuPG’s own project documentation echoes the same framing when describing its design goals, stating that “GnuPG tries to be a very flexible implementation of the OpenPGP standard,” a line that explains why the project supports both cutting-edge curve algorithms and legacy RSA in the same binary, letting users choose based on their compatibility needs rather than forcing a single path. The documentation is equally direct about day-to-day behavior, noting in its reference manual that “the default is to create the binary OpenPGP format” when no other output option is specified.
Walfield’s own account of starting Sequoia PGP, a newer Rust-based OpenPGP implementation, underlines just how central GnuPG has been to this ecosystem. Describing the project’s origins in an interview, he recalled that “the three of us had previously worked on GnuPG, the most common OpenPGP implementation at the time,” a reminder that even developers building alternatives to GnuPG still treat it as the reference point for what an OpenPGP implementation should do.
6 Use Cases: Which One Should You Actually Pick
- Individual developer signing Git commits or software releases: use GPG. It is free, scriptable, integrates directly with Git and GitHub, and an Ed25519 key takes seconds to generate.
- Linux distribution or package maintainer: use GPG with an Ed25519 signing subkey for speed, keeping an RSA-4096 key around only if you need compatibility with older package-management tooling.
- Journalist, source, or security researcher handling sensitive documents: use GPG, ideally inside a compartmentalized setup like Qubes OS Split GPG, so a compromised application never touches the raw private key.
- General email encryption for a small team: use GPG through Mailvelope or Proton Mail’s OpenPGP-interoperable workflow rather than paying for a commercial suite you do not need.
- Regulated enterprise needing a vendor contract and compliance audit trail: commercial PGP from Broadcom makes sense here specifically because procurement and compliance teams need a support agreement and centralized key escrow, not because the cryptography differs.
- Mixed environment with old hardware security tokens or legacy partners: stick with RSA-3072 or RSA-4096 keys in GPG until every partner in the exchange supports the newer RFC 9580 curve encodings, then migrate.
Migration Guide: Moving From Legacy RSA Keys or Commercial PGP to Modern GnuPG
If you are still running an old RSA-2048 key from a decade ago, or you want to move a team off a commercial PGP license and onto free GnuPG, the transition is straightforward if you do it in order rather than all at once.
- Audit your current keys first. List every key that signs releases, encrypts backups, or verifies packages, and note its algorithm, expiration date, and where the private key is stored.
- Install current GnuPG. On Linux, update through your package manager; on Windows, install the current Gpg4win release (5.1.1 at the time of writing); on macOS, install GPG Suite or GnuPG via Homebrew.
- Generate a new Ed25519 signing key with an X25519 encryption subkey. Set a real expiration date instead of “never expires,” which makes future key rotation far less painful.
- Cross-sign the new key with the old one. Signing your new key with your existing, trusted key gives anyone who already trusts you a clear, verifiable path to your new identity instead of asking them to blindly trust a brand-new key.
- Publish the new key to a keyserver and your Web Key Directory. This lets mail clients and tools automatically discover the new key without manual key-exchange emails.
- Update dependent systems one at a time. Reconfigure APT/RPM repository signing, CI/CD release pipelines, and email clients to use the new key, testing each integration before moving to the next.
- Keep the old key valid during a transition window. Do not revoke the legacy RSA key immediately. Give collaborators and automated systems time to pick up the new key.
- Revoke and publish the revocation certificate for the old key once migration is confirmed. This closes the loop and tells anyone still holding the old key that it is retired.
Teams moving off a commercial PGP license follow the same core steps, with one addition: export and securely archive any centrally escrowed keys from the commercial key management server before canceling the contract, since GnuPG does not provide an equivalent built-in escrow system out of the box.
Pros and Cons: PGP vs GPG Side by Side
GPG (GnuPG) pros:
- Free and open source under the GNU GPL, with no per-seat licensing cost.
- Runs on Linux, Windows, and macOS with active, publicly tracked release notes.
- Supports the full modern OpenPGP algorithm set, including Ed25519 and X25519.
- Deeply integrated into package managers, Git, and open-source infrastructure.
- Smartcard and hardware token support through the OpenPGP card standard.
GPG (GnuPG) cons:
- No built-in centralized key escrow or recovery for enterprise compliance needs.
- Support comes from the community or third parties rather than a vendor SLA.
- Command-line-first design still intimidates non-technical users without a GUI front-end.
Commercial PGP (Broadcom/Symantec) pros:
- Centralized key management server built for enterprise compliance and audit trails.
- Dedicated vendor support contract and SLA.
- Polished enterprise console aimed at non-technical IT administrators.
Commercial PGP (Broadcom/Symantec) cons:
- Quote-based licensing with no public pricing, making budgeting harder.
- Closed-source, so independent security researchers cannot audit the code directly.
- Release and patch notes are less publicly detailed than GnuPG’s public changelog.
The Verdict: PGP vs GPG in 2026
For the overwhelming majority of developers, sysadmins, and even most small businesses, GPG is the right answer in 2026. It costs nothing, implements the current RFC 9580 standard, and already runs the infrastructure you depend on every day, from Debian’s package signing to Git’s commit verification. The benchmark data backs up the algorithm choice too: Ed25519 and X25519 give you the speed and compact key size that RFC 9580 now requires as a baseline, while RSA remains available for the cases where compatibility with older systems still matters more than raw performance.
Commercial PGP from Broadcom is not obsolete. It earns its quote-based price tag in regulated industries that need a signed support contract, centralized key escrow, and a vendor to answer for during a compliance audit. If your organization genuinely needs those enterprise features and is willing to pay for them, that is a legitimate reason to buy rather than build on top of free tooling. But if you are choosing based on cryptographic strength alone, the honest answer is that both sides are implementing the same standard, and the free one is actively maintained, publicly audited, and already proven at scale across the open-source world.
Frequently Asked Questions
Is PGP the same thing as GPG?
No. PGP is the original commercial product lineage, now owned by Broadcom, while GPG (GnuPG) is a separate, free, open-source implementation of the OpenPGP standard that both trace back to. They produce compatible encrypted messages because they both follow the same OpenPGP specification.
Can GPG open files encrypted with commercial PGP software, or vice versa?
In almost all cases, yes, because both implement the OpenPGP format defined in RFC 9580 and its predecessors. The main exception is if one side uses an algorithm or encoding the other does not support, such as a very old implementation that has not added support for the newer Ed25519/X25519 encodings.
Is GPG actually free, with no hidden costs?
Yes. GnuPG is licensed under the GNU GPL and distributed at no cost, as are common front-ends like Gpg4win, Kleopatra, and Mailvelope. Some macOS tooling like GPG Suite offers an optional paid tier for extended support, but the core encryption software itself remains free.
What algorithm does GPG use by default for new keys in 2026?
Current GnuPG releases and the RFC 9580 standard point toward an Ed25519 signing key paired with an X25519 encryption subkey as the modern default, replacing the RSA-centric defaults that were standard a decade ago.
Is RSA-4096 still secure for PGP or GPG keys in 2026?
Yes, RSA-4096 remains cryptographically sound for OpenPGP use. It is simply slower than modern curve algorithms for signing operations, and it produces larger keys and signatures, which is why newer deployments default to Ed25519 and X25519 instead.
What happened to the original PGP Corporation?
Symantec acquired PGP Corporation in 2010 and folded its products into Symantec’s enterprise encryption lineup. When Broadcom acquired Symantec’s enterprise security business in 2019, those PGP-branded commercial products, including Encryption Desktop and Command Line, became part of Broadcom’s portfolio.
Can I use GPG for everyday email encryption?
Yes. Tools like Mailvelope add OpenPGP encryption directly to webmail interfaces such as Gmail, and Proton Mail supports OpenPGP-compatible workflows for exchanging encrypted mail with people outside its own platform.
Is OpenPGP (and therefore PGP and GPG) safe from quantum computers?
Not yet. Both RSA and the elliptic-curve algorithms used in current OpenPGP keys, including Ed25519 and X25519, would be vulnerable to a sufficiently powerful quantum computer running Shor’s algorithm. As of October 2026, RFC 9580 does not mandate a post-quantum algorithm, so OpenPGP’s long-term quantum resistance is still an open area of standards work rather than a solved problem.
Do I need to pick either RSA or Ed25519, or can one key use both?
Most OpenPGP setups use a primary key for certification plus one or more subkeys for signing and encryption, so it is common to generate a primary key on one algorithm and add subkeys on another while you transition. This lets you keep an RSA subkey around for compatibility while signing new work with an Ed25519 subkey, rather than forcing an all-or-nothing switch.
Why does GitHub show “Verified” on some commits but not others?
GitHub shows a “Verified” badge when a commit is signed with a key, GPG or otherwise, that has been linked to the committer’s GitHub account and matches the committer’s registered identity. An unsigned commit, or one signed with a key GitHub cannot match to the account, will not display that badge even if the commit content is identical.