RSA has run the internet’s public-key cryptography for nearly 50 years, but it isn’t the only asymmetric cipher built on hard math. ElGamal encryption, designed by Taher Elgamal in 1985 and still living inside GnuPG today, takes a different route to the same goal: scrambling a message so only the holder of a private key can read it. In October 2026, with NIST’s post-quantum transition clock ticking and most engineers never having run the two side by side, the question of how RSA and ElGamal actually compare on speed, ciphertext size, and real-world support keeps surfacing in forums and classrooms alike. This piece runs the numbers: benchmark data from three published studies, our own OpenSSL 3.0.13 test run, current cloud and certificate pricing, and a practical migration path for anyone still holding a legacy ElGamal subkey.
How RSA and ElGamal Emerged From the Same Decade
Both algorithms trace back to the same burst of public-key cryptography research that followed Whitfield Diffie and Martin Hellman’s 1976 breakthrough showing that two parties could agree on a shared secret over an open channel without ever meeting. RSA followed in 1977, built directly on integer factorization, and quickly became the default choice once early implementations shipped in commercial software. ElGamal arrived eight years later, in 1985, generalizing the Diffie-Hellman key-exchange idea into a full public-key encryption scheme built on the discrete logarithm problem rather than factoring.
That shared lineage matters for understanding why the two algorithms keep getting compared instead of treated as unrelated technologies. Both are asymmetric ciphers solving the same problem (secure communication without a pre-shared secret) using two different number-theoretic hard problems. RSA bet on factoring staying hard, ElGamal bet on discrete logarithms staying hard. Decades of cryptanalysis have left both bets intact against classical computers, which is exactly why the comparison in this article is about performance, tooling, and ciphertext size rather than one algorithm having been broken and the other surviving.
What Is RSA Encryption?
RSA (Rivest-Shamir-Adleman) is a public-key cryptosystem built on the difficulty of factoring the product of two large prime numbers. A user generates a modulus by multiplying two primes together, derives a public exponent and a private exponent from that modulus, and publishes the public pair while keeping the private exponent secret. Anyone can encrypt a message with the public key, but only the private-key holder can reverse the operation and recover the plaintext. The same math, run in the opposite direction, produces RSA digital signatures.
Textbook RSA, meaning raw modular exponentiation with no padding, is deterministic and insecure in practice: the same plaintext always produces the same ciphertext, which leaks information and opens the door to chosen-ciphertext attacks. Modern deployments use RSA-OAEP (Optimal Asymmetric Encryption Padding) for encryption and RSA-PSS for signatures, both of which add randomness before the exponentiation step. A ciphertext produced by RSA-OAEP is always exactly the size of the modulus. For an RSA-2048 key, that is 256 bytes, regardless of how short the original message was.
RSA’s dominant real-world role today is in the public-key infrastructure (PKI) that underpins HTTPS. Every major certificate authority, from DigiCert to Sectigo to the free automated issuer Let’s Encrypt, offers RSA certificates as a baseline option alongside ECDSA, and most TLS libraries, hardware security modules (HSMs), and cloud key-management services treat RSA as a first-class citizen.
What Is ElGamal Encryption?
ElGamal encryption is built on a different hard problem: the discrete logarithm problem in a finite cyclic group (or, in some implementations, on elliptic curves). Instead of factoring a number, an attacker trying to break ElGamal would need to recover a secret exponent from a public value raised to that exponent inside a large group, something no efficient classical algorithm is known to do. Encryption works by combining the recipient’s public key with a fresh, random ephemeral exponent chosen for every single message, and the output is always two group elements rather than one, commonly written as the pair (g^k, m times y^k).
That two-element output is the defining structural difference from RSA. Where RSA-OAEP ciphertext is exactly one modulus wide, ElGamal ciphertext is roughly two group elements wide for every message, meaning it carries intrinsically more overhead no matter how the group or encoding is chosen. The upside is that ElGamal encryption is randomized by construction: there is no “textbook ElGamal is insecure” caveat the way there is for textbook RSA, because the randomness is baked into the scheme itself rather than bolted on through a padding scheme.
ElGamal’s clearest foothold in production software today is GnuPG and the OpenPGP ecosystem. GnuPG’s own documentation confirms support for ElGamal encryption keys from 1024 through 4096 bits, and the classic OpenPGP key layout paired a DSA primary key for signing with an ElGamal subkey for encryption, a structure the GNU Privacy Handbook still documents for anyone working with legacy keys. GnuPG’s FAQ also states the project no longer supports the separate ElGamal signature algorithm, only ElGamal for encryption, a detail that trips up a lot of people cleaning out old keyrings.
RSA vs ElGamal: Full Specification Comparison
The table below lines up the two algorithms across the properties that actually matter when you’re choosing one for a real system: the hard math problem each relies on, typical key sizes, ciphertext behavior, and where each one is supported in practice.
| Property | RSA | ElGamal |
|---|---|---|
| Underlying hard problem | Integer factorization | Discrete logarithm problem |
| Year introduced | 1977 | 1985 |
| Key size for ~112-bit security | 2048 bits | No single NIST finite-field equivalence table; depends on group/parameter choice |
| Key size for ~128-bit security | 3072 bits | Group-dependent; not standardized the same way |
| Ciphertext size (relative) | Exactly one modulus width (e.g., 256 bytes at RSA-2048) | Approximately two group elements per message |
| Encryption randomization | Only via padding (RSA-OAEP); textbook RSA is deterministic | Randomized natively via a fresh ephemeral exponent per message |
| Security property (as deployed) | RSA-OAEP targets IND-CCA2 | Plain ElGamal is IND-CPA but multiplicatively malleable, not IND-CCA2 without an added transform |
| Signature variant | RSA-PSS | Original ElGamal signatures; DSA (FIPS 186) is derived from this structure |
| Supported by GnuPG | Yes, full support | Encryption only; signature support dropped per GnuPG FAQ |
| Supported by major commercial CAs | Yes (DigiCert, Sectigo, Let’s Encrypt) | No publicly trusted CA issues ElGamal TLS certificates |
| Supported by AWS KMS / Google Cloud KMS / Azure Key Vault | Yes | No documented support found in any of the three |
| Hardware security module (HSM) support | Broad, including AWS CloudHSM and Google Cloud HSM | Effectively none in commercial HSMs |
| NIST post-quantum migration status | Named explicitly in CNSA 2.0 and NIST IR 8547 transition planning | Equally quantum-vulnerable (discrete log falls to Shor’s algorithm) but less frequently named directly since it’s rarely deployed at scale |
Key Sizes: How Much Security Do You Actually Get?
Security strength in public-key cryptography isn’t measured in key bits directly, it’s measured in the equivalent work an attacker would need to break the key, usually expressed in “bits of security.” For RSA, the equivalence tables tied to NIST SP 800-131A guidance put RSA-2048 at roughly 112-bit classical security. RSA-3072 steps that up to approximately 128-bit security, which is the baseline NIST transition guidance targets for keys expected to remain in service past 2030. Push further and RSA-7680 lands around 192-bit security, with RSA-15360, a genuinely unwieldy key size in practice, needed to reach roughly 256-bit security.
ElGamal doesn’t have an equivalent, universally cited NIST finite-field key-size table the way RSA does. Its security depends heavily on which group it’s implemented over (a multiplicative group modulo a prime, or an elliptic-curve group) and on the specific discrete-logarithm hardness assumptions chosen for that group. That means an “ElGamal-2048” label is not automatically equivalent in strength to an RSA-2048 key. The two numbers describe different structures doing different amounts of mathematical work, and treating them as interchangeable is one of the more common mistakes in casual comparisons of the two systems.
What this means practically: if you’re choosing RSA, the key-size-to-security mapping is well documented and you can pick a number straight from NIST guidance. If you’re evaluating ElGamal, you need to know the specific group parameters your implementation uses (GnuPG, for instance, documents support from 1024 through 4096 bits) and should not assume a given bit length buys the same protection RSA would offer at that size.
Ciphertext Expansion: Why ElGamal Messages Run Bigger
This is the most concrete, least debatable difference between the two systems. RSA-OAEP always produces a ciphertext exactly as wide as the modulus: 256 bytes for RSA-2048, 384 bytes for RSA-3072, no more and no less, regardless of the plaintext length (padding simply eats into the usable capacity). ElGamal, by contrast, structurally outputs two group elements for every encrypted message, roughly doubling the ciphertext’s footprint relative to a single-element scheme at a comparable parameter size.
For storage-constrained systems, bandwidth-sensitive protocols, or anything encrypting large volumes of small messages, that doubling adds up. It’s also one of the quieter reasons ElGamal never displaced RSA in TLS: certificate chains, handshake messages, and session setup all have practical size budgets, and a scheme that structurally needs twice the bytes per operation is a harder sell even before you get to speed.
Benchmark Results: Encryption and Decryption Speed Compared
We ran our own local benchmark using OpenSSL 3.0.13’s built-in openssl speed tool, which doesn’t include a standalone ElGamal mode but gives a clean baseline for RSA’s raw operation throughput. Signing (the private-key operation) and verification (the public-key operation) were each measured over a 10-second window:
| Study / source | Key size | RSA result | ElGamal result |
|---|---|---|---|
| Our OpenSSL 3.0.13 benchmark (sign/verify ops per second) | 2048-bit | 1,050.5 signs/sec, 30,087.5 verifies/sec | Not applicable (no native OpenSSL ElGamal speed mode) |
| Our OpenSSL 3.0.13 benchmark (sign/verify ops per second) | 3072-bit | 248.1 signs/sec, 12,822.0 verifies/sec | Not applicable |
| SciSpace-hosted comparative cryptosystem study | 1024-bit | 0.139s encrypt / 0.231s decrypt | 0.703s encrypt / 0.305s decrypt |
| SciSpace-hosted comparative cryptosystem study | 2048-bit | 0.561s encrypt / 0.631s decrypt | 1.107s encrypt / 0.705s decrypt |
| Frontiers in Computer Science, 2025 (22 KB plaintext) | Not specified in extract | 108.2ms mean encryption, 203.3 KB/s throughput | 1,550ms mean encryption, 14.2 KB/s throughput |
| EAI conference paper, 2018 | 1024/2048-bit | Comparable key-generation time; better encryption/decryption performance | Comparable key-generation time; slower encryption/decryption in the study’s measurements |
Three independently published comparisons, run with different implementations, message sizes, and hardware, all land in the same place: RSA encrypts and decrypts faster than ElGamal at comparable key sizes, and the gap widens as plaintext size grows. The 2025 Frontiers in Computer Science paper found the largest spread, with RSA encrypting a 22 KB payload roughly 14 times faster than ElGamal in the same test harness. The SciSpace-hosted study found a smaller but still consistent gap at both 1024-bit and 2048-bit sizes. None of these numbers should be read as universal constants, implementation, language, and hardware all move the absolute figures, but the direction of the gap is remarkably consistent across a 2018 conference paper, a 2025 peer-reviewed journal article, and an independent SciSpace-indexed comparative study.
The reason tracks back to the math: ElGamal encryption requires generating a fresh random exponent and performing multiple modular exponentiations for every message, while RSA encryption with a small public exponent (commonly 65537) is comparatively cheap. RSA’s private-key operation (decryption or signing) is the more expensive side of its own ledger, but it still comes out ahead of ElGamal’s two-exponentiation encryption step in most published tests.
One caveat worth flagging for anyone benchmarking either algorithm themselves: neither RSA nor ElGamal is typically used to encrypt large payloads directly in production. Real-world systems use hybrid encryption, a fast symmetric cipher like AES-256-GCM handles the bulk data, and the public-key algorithm only wraps a short symmetric session key. That’s precisely why the 22 KB test in the 2025 Frontiers in Computer Science paper shows such a dramatic gap: it’s stress-testing a scenario public-key cryptography almost never faces on its own in a real deployment, which makes the gap at small message or key-wrapping sizes (the SciSpace-hosted 1024-bit and 2048-bit figures) more representative of everyday workloads than the large-payload numbers are.
Security Properties: Malleability, IND-CPA, and IND-CCA2
Speed and ciphertext size are only half the comparison. The security properties each scheme provides, as actually deployed, matter just as much. Plain ElGamal encryption is randomized and generally IND-CPA secure (indistinguishable under chosen-plaintext attack) under standard discrete-log-type assumptions, but it is multiplicatively malleable: an attacker who intercepts a ciphertext can transform it into a different, related ciphertext without ever learning the underlying plaintext. That malleability means plain ElGamal does not meet the stronger IND-CCA2 bar (indistinguishable under adaptive chosen-ciphertext attack) without an additional transformation layered on top, such as the Cramer-Shoup construction or a Fujisaki-Okamoto-style hybrid.
RSA has the mirror-image history. Textbook RSA, raw exponentiation with no padding, is both deterministic and malleable, which is exactly why it’s considered broken for direct use. RSA-OAEP was specifically designed to close that gap, and in its standard construction is built to meet IND-CCA2 in the random oracle model. In practical terms: neither algorithm is safe to use in its “textbook” form, but the padded, standardized version of RSA (OAEP) that ships in real TLS libraries has a cleaner, more battle-tested security story than plain ElGamal does without extra scaffolding.
Implementation bugs matter as much as algorithm design here. A real vulnerability tracked in Libgcrypt’s public CVE history, GnuPG’s underlying cryptographic library, affected ElGamal encryption specifically because of missing exponent blinding combined with an unsuitable window size in the library’s modular-exponentiation routine (mpi_powm). The flaw hit Libgcrypt versions before 1.8.8 and the 1.9.x series before 1.9.3, a reminder that side-channel resistance in the implementation can matter as much as the underlying math, for either algorithm.
How ElGamal Relates to Diffie-Hellman and DSA
ElGamal rarely gets discussed in isolation because its discrete-logarithm structure is shared with two other cryptographic workhorses: Diffie-Hellman key exchange and DSA, the Digital Signature Algorithm standardized in NIST FIPS 186. Diffie-Hellman and ElGamal encryption are close cousins, both rely on the hardness of computing discrete logarithms in a group, and ElGamal can be understood as applying the Diffie-Hellman key-agreement idea to encrypt a specific message rather than to derive a shared session key for later use.
DSA’s relationship runs deeper still. The ElGamal signature scheme (distinct from ElGamal encryption, a point worth repeating since the two get conflated constantly) predates DSA and uses a similar ephemeral-exponent structure. DSA modifies that structure by reducing values modulo a smaller subgroup order and using a different verification equation, which shrinks signature size compared to the original ElGamal signature construction. That inheritance is why GnuPG’s historical key format paired a DSA primary key for signing with an ElGamal subkey for encryption: the two were seen as complementary halves of the same discrete-log family rather than as competing designs. It’s also why NIST’s own documentation and the GnuPG Project’s FAQ discuss DSA and ElGamal in the same breath, as noted earlier, including the shared observation that discrete-log algorithms need only one random prime where RSA key generation needs two, a detail with real implications for random-number-generator weaknesses in constrained environments.
Real-World Deployments: Where Each Algorithm Actually Runs
RSA’s footprint is close to total coverage of public-key infrastructure. Web TLS certificates from every major certificate authority, code-signing certificates, SSH host keys, document-signing workflows, and the asymmetric key support inside every major cloud KMS all default to or fully support RSA. ElGamal’s footprint, by contrast, is narrow but not zero. Five concrete places each algorithm shows up today:
- GnuPG and legacy OpenPGP keyrings — classic PGP key sets paired a DSA primary signing key with an ElGamal encryption subkey, a layout GnuPG still reads and the GNU Privacy Handbook documents for backward compatibility.
- Public Web PKI (RSA only): DigiCert, Sectigo, and Let’s Encrypt all issue RSA (and increasingly ECDSA) certificates, and none of the three offers ElGamal as a certificate key type.
- Cloud key-management services (RSA only): AWS KMS, Google Cloud KMS, and Azure Key Vault all support RSA asymmetric keys for encryption and signing, with no documented ElGamal support in any of the three.
- Hardware security modules (RSA only): commercial HSM offerings, including AWS CloudHSM and Google Cloud HSM, provision RSA keys as standard. ElGamal is effectively absent from the commercial HSM market.
- Academic cryptography research and coursework (ElGamal’s main modern home) — the clean algebraic structure of ElGamal makes it the standard textbook example for discrete-log-based public-key systems, which is exactly why it keeps showing up in comparative benchmark papers like the ones cited above, rather than in production traffic.
The pattern is consistent: anywhere a commercial vendor, cloud provider, or certificate authority had to pick one asymmetric algorithm to support, RSA won by default, and ElGamal’s surviving presence is concentrated in GnuPG’s legacy key format and in research literature rather than in production infrastructure.
Cost to Deploy: Certificates, HSMs, and Cloud KMS Pricing
Because ElGamal has no presence in the commercial certificate or cloud key-management market, there’s no ElGamal price point to compare against RSA’s. The honest comparison is what it costs to run RSA in production today, set against the fact that ElGamal simply isn’t a purchasable option at any price from these vendors.
| Service | RSA pricing (2026) | ElGamal availability |
|---|---|---|
| AWS KMS customer-managed asymmetric key | $1.00 per key, per month | Not offered |
| AWS KMS asymmetric key requests | $0.03 per 10,000 requests (Sign, Verify, Encrypt, Decrypt); excluded from the free tier | Not applicable |
| Google Cloud single-tenant Cloud HSM | $4.794520548 per instance-hour, includes capacity for 15,000 key versions | Not offered |
| AWS CloudHSM | Roughly $1.60 per HSM-hour; a two-HSM production cluster running continuously for 31 days runs about $2,380.80 | Not offered |
| DigiCert RSA TLS certificate | Roughly $248/year entry-level DV, $409+/year for higher-tier products | Not offered |
| Sectigo RSA TLS certificate | Roughly $7.66/year reseller DV, around $69/year for OV | Not offered |
| Let’s Encrypt RSA certificate | Free, automated, 90-day validity | Not offered |
| GnuPG ElGamal encryption subkey (open source) | Not applicable | Free, self-generated, 1024-4096 bits per GnuPG’s own documentation |
The takeaway from the pricing table is less about dollar figures and more about market reality: RSA has a fully priced, competitive commercial ecosystem around it, from free DV certificates to metered cloud key operations to dedicated HSM hardware. ElGamal has none of that. If you need ElGamal today, your only realistic path is GnuPG or a general-purpose cryptography library like OpenSSL’s legacy engine or Libgcrypt, run entirely on infrastructure you manage yourself.
Migration Guide: Moving Off Legacy ElGamal and DSA Keys
If you’re holding an old PGP or GnuPG key with a DSA primary and an ElGamal encryption subkey, generated years ago under GnuPG’s old defaults, here’s a practical path to modernize it without losing your web of trust or your ability to read old encrypted mail. The same discipline applies even if your keys are plain RSA rather than ElGamal: anyone still on RSA-1024 or RSA-2048 should be moving toward RSA-3072 or ECC on the same timeline, since the NIST transition guidance discussed above treats key-size adequacy and algorithm family as separate questions that both need answering.
- Inventory what you have: run
gpg --list-keys --with-colonsand look for algorithm identifiers 16 (ElGamal encrypt-only) or 20 (ElGamal sign-and-encrypt, deprecated) on any subkey or primary key. - Confirm your GnuPG version with
gpg --version, since current GnuPG no longer creates new ElGamal signing keys and recommends encryption-only use where ElGamal appears at all. - Generate a new primary key on modern parameters, for example
gpg --quick-generate-key "Name <email>" ed25519 cert never, orrsa4096if you need broader compatibility with tools that don’t yet support Curve25519. - Add a matching modern encryption subkey, such as
gpg --quick-add-key <fingerprint> cv25519 encrorrsa3072 encr, to replace the role the old ElGamal subkey played. - Set a sane expiration on the new key with
gpg --quick-set-expire <fingerprint> 2yso it rotates on a predictable schedule going forward. - Publish the new key to keyservers and any Web Key Directory (WKD) you use, and cross-sign it with the old key while the old key is still valid, to carry your existing web of trust forward.
- Re-encrypt anything you still need access to under the new key where that’s feasible. Anything encrypted purely to the old ElGamal subkey will still need that old private key to decrypt.
- Generate and publish a revocation certificate for the old key with
gpg --gen-revokerather than deleting it outright, so signatures made with it remain verifiable historically. - Update any scripts, CI pipelines, or automation that reference the old key ID or fingerprint directly.
- Set a calendar reminder tied to your organization’s crypto-period policy, and align your next rotation with NIST’s proposed RSA transition checkpoints around 2030, since whatever you migrate to next will likely need another look by then.
RSA Pros and Cons
RSA’s strongest argument is simply how battle-tested and universally supported it is. Nearly 50 years of cryptanalysis have left the core factoring problem intact at properly chosen key sizes, every CA and cloud provider supports it natively, and its public-key operation (encryption or verification) is fast enough to be nearly free in most applications thanks to small public exponents. The costs are real too: key sizes have to keep growing to hold a target security level (3072 bits for 128-bit security per NIST guidance, versus the much smaller keys ECC needs for the same strength), key generation is computationally heavier than ECC-based alternatives, and RSA sits squarely on NIST’s and CNSA 2.0’s quantum-migration timeline, meaning its long-term runway is explicitly finite.
ElGamal Pros and Cons
ElGamal’s structural advantage is that randomization is native to the scheme itself rather than something bolted on through padding, so there’s no “never use it unpadded” footgun the way there is with textbook RSA. It also remains genuinely useful as a teaching tool and research benchmark subject, since its algebraic structure maps cleanly onto broader discrete-log cryptography, including Diffie-Hellman and DSA. The downsides are significant for production use, though: ciphertext runs roughly double the size of a comparable single-element scheme, three independent benchmark studies all found it slower than RSA at comparable key sizes, plain ElGamal is malleable without an added transform, zero commercial CAs or cloud KMS providers support it, GnuPG dropped its signature variant entirely, and it carries the same long-term quantum vulnerability as RSA with far less institutional attention paid to migrating it.
Which One Should You Use? Five Real-World Scenarios
- Running a public HTTPS website or API: use RSA (or ECDSA). Every CA, browser, and load balancer supports it, and ElGamal isn’t an option at any certificate authority.
- You have an old PGP key with an ElGamal subkey: don’t panic, old encrypted mail still needs that key to decrypt, but generate a new primary on RSA-3072/4096 or modern ECC for anything going forward, following the migration steps above.
- Teaching or studying discrete-log-based cryptography: ElGamal remains the cleanest textbook example and the one most comparative benchmark papers (SciSpace, Frontiers, EAI) use as their reference implementation.
- Enterprise workloads on cloud HSMs or KMS: RSA is the only realistic choice. Budget roughly $1/key-month plus per-request fees on AWS KMS, or around $4.79/instance-hour for Google’s single-tenant Cloud HSM.
- Government or national-security systems under CNSA 2.0: plan RSA’s phase-out on NIST’s proposed 2030/2035 timeline regardless of which classical algorithm you currently run, since both RSA and ElGamal fall to the same quantum attack (Shor’s algorithm) and neither is a long-term answer.
What Cryptographers and Standards Bodies Say
Security researcher and cryptographer Bruce Schneier has written about both algorithms’ place in the broader public-key landscape. Describing the family of asymmetric ciphers in a PGP overview, he noted that “some examples of public-key cryptosystems are Elgamal (named for its inventor, Taher Elgamal), RSA (named for its inventors, Ron Rivest, Adi Shamir, and Leonard Adleman), Diffie-Hellman (named, you guessed it, for its inventors), and DSA, the Digital Signature Algorithm (invented by David Kravitz),” according to a PGP introduction that reproduces his explanation of the field. In the same overview, Schneier framed the basic mechanism plainly: “Public key cryptography is an asymmetric scheme that uses a pair of keys for encryption: a public key, which encrypts data, and a corresponding private, or secret key for decryption.”
On the specific question of random-number weaknesses, which hit RSA and discrete-log systems differently, Schneier pointed out on his blog that “discrete log based algorithms, like DSA and ElGamal, are less susceptible to this vulnerability because they only need one random prime,” a structural distinction he drew while discussing weak random-number generation affecting public keys found in the field.
The GnuPG Project’s own documentation is more narrowly practical, noting in its compatibility guidance that “the standard distribution of GnuPG does not support PGP 2.x keys since PGP 2.x uses IDEA as its symmetric cipher and RSA for its public key cipher,” a reminder that even within RSA’s camp, compatibility has never been automatic across every historical implementation.
The Post-Quantum Deadline Both Algorithms Face
Here’s the detail that gets lost in most RSA-vs-ElGamal comparisons: neither algorithm has a long-term future. Both rely on mathematical problems, integer factorization for RSA, discrete logarithms for ElGamal, that Shor’s algorithm breaks efficiently on a sufficiently large quantum computer. NIST’s draft transition guidance, described in NIST IR 8547, proposes deprecating quantum-vulnerable public-key algorithms including RSA after 2030 and disallowing them after 2035. The National Security Agency’s Commercial National Security Algorithm Suite (CNSA 2.0) sets its own parallel schedule for U.S. national-security systems: new acquisitions must be quantum-resistant compliant by 2027, with legacy equipment and services phased out by 2030 and a broader 2035 target for full quantum-resistant coverage.
CNSA 2.0 applies directly only to U.S. national-security systems rather than every commercial deployment, but it functions as a widely referenced planning benchmark across the industry, as outlined in Encryption Consulting’s published analysis of RSA’s retirement timeline. For organizations running either RSA or ElGamal today, the practical implication is the same regardless of which classical algorithm you pick: both need a post-quantum successor, typically ML-KEM (Kyber) for key encapsulation and ML-DSA (Dilithium) for signatures, on a roughly similar clock. Choosing RSA over ElGamal today buys you better tooling, support, and speed in the near term, not a longer runway against quantum computers.
Verdict: RSA vs ElGamal in 2026
On every measurable axis in this comparison, RSA is the practical choice for new systems in 2026. It encrypts and decrypts faster across three independent benchmark studies, spanning gaps from roughly 2x at small message sizes up to the 14x difference the 2025 Frontiers in Computer Science study measured on larger payloads. Its ciphertext is smaller by design (one modulus width versus roughly two group elements). It has a well-documented NIST key-size-to-security mapping that ElGamal simply lacks in the same standardized form. And it’s the only one of the two with any commercial ecosystem behind it: every major CA, every major cloud KMS, and every commercial HSM vendor checked here supports RSA, while none support ElGamal.
ElGamal isn’t obsolete so much as it was never widely commercialized outside of GnuPG’s legacy key format, where it still functions correctly for anyone holding an older key. Its genuinely randomized-by-design encryption is a real theoretical advantage over unpadded RSA, and it remains a useful teaching tool for discrete-log cryptography precisely because its structure is so clean. But for anyone building new infrastructure today, picking between the two isn’t really a contest: RSA wins on speed, size, tooling, and support, and the one place ElGamal still has a foothold is a format most security teams are actively migrating away from anyway, toward either modern RSA key sizes or ECC, with a post-quantum successor already on the calendar for both.
Frequently Asked Questions
Is ElGamal encryption still used anywhere today?
Mostly inside GnuPG and legacy OpenPGP keyrings, where older keys paired a DSA primary with an ElGamal encryption subkey. It also persists in academic cryptography research and benchmark studies, but no commercial certificate authority, cloud KMS, or HSM vendor supports it.
Is ElGamal more secure than RSA?
Neither is inherently more secure. They rely on different hard problems (discrete logarithm versus integer factorization) that are both considered hard for classical computers and both breakable by a sufficiently powerful quantum computer via Shor’s algorithm. Security in practice depends more on implementation, padding, and key-size choices than on which family you pick.
Why does ElGamal produce bigger ciphertexts than RSA?
ElGamal encryption structurally outputs two group elements for every message (commonly written as g^k and m times y^k), while RSA-OAEP always produces a ciphertext exactly one modulus wide. That’s a built-in feature of ElGamal’s design, not an implementation flaw.
Can I still generate ElGamal keys in GnuPG?
GnuPG’s FAQ documents support for ElGamal encryption keys from 1024 through 4096 bits, but the project no longer supports the separate ElGamal signature algorithm. Encryption-only ElGamal subkeys remain functional for reading legacy messages.
Is RSA being phased out?
Not immediately, but it is on a documented transition timeline. NIST’s draft guidance (NIST IR 8547) proposes deprecating RSA after 2030 and disallowing it after 2035, and CNSA 2.0 sets a 2027 compliance deadline for new national-security-system acquisitions with legacy phase-out by 2030.
What’s the difference between ElGamal encryption and ElGamal-style signatures?
They’re related but distinct constructions built on the same discrete-log math. ElGamal encryption scrambles a message for confidentiality, while the ElGamal signature scheme (and its direct descendant, DSA under FIPS 186) authenticates a message instead. GnuPG still supports ElGamal for encryption but dropped support for the ElGamal signature variant.
Which is faster, RSA or ElGamal?
RSA, consistently, across every published benchmark we found. A 2025 study in Frontiers in Computer Science measured RSA encrypting roughly 14 times faster than ElGamal on a 22 KB payload, and a separate comparative study found smaller but still consistent gaps at 1024-bit and 2048-bit key sizes.
Should I worry about my old PGP key if it has an ElGamal subkey?
Not urgently. ElGamal encryption itself isn’t broken when implemented correctly (the known Libgcrypt vulnerability was fixed in versions 1.8.8 and 1.9.3). But since no modern commercial tooling supports ElGamal and GnuPG’s own defaults have moved on, it’s worth generating a new RSA or ECC-based key and migrating over time using the steps outlined above.
