RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

RSA & ECC Keypair Generator

Generate RSA keypairs in PKCS#8 and SPKI PEM using the browser's own Web Crypto implementation. Private key material never leaves local memory.

Open Air-Gapped Keypair Generator →

Two Ways to Build a Trapdoor

Asymmetric cryptography needs a function that is easy forwards and infeasible backwards. RSA and ECC pick different hard problems:

RSA (RFC 8017) relies on the difficulty of factoring a modulus n = p × q into its two large primes. Public key: (n, e). Private key: (n, d) plus the CRT parameters that make decryption fast.
ECC relies on the elliptic curve discrete logarithm problem: given points G and Q = kG on a curve, recover the scalar k. Public key: the point Q. Private key: the scalar k.

The consequence is not academic. The best classical attack on RSA — the general number field sieve — runs in sub-exponential time, so RSA key sizes must grow steeply to keep pace with hardware. The best generic attack on a well-chosen curve is Pollard’s rho at roughly the square root of the group order, so ECC key sizes grow linearly with security. That single difference explains the entire comparison table below.

What you get from this guide: a defensible key-size choice, the ability to read any PEM file you are handed, and a clear view of what post-quantum migration does and does not demand of you today.

Security Strength: The Only Fair Comparison

Key length is meaningless across algorithm families. The comparable unit is security strength in bits, expressed as the equivalent symmetric key.

Security strength	RSA modulus	Elliptic curve	Symmetric equivalent
112 bits	RSA-2048	P-224	3TDEA (legacy)
128 bits	RSA-3072	P-256 (secp256r1)	AES-128
192 bits	RSA-7680	P-384 (secp384r1)	AES-192
256 bits	RSA-15360	P-521 (secp521r1)	AES-256

Two practical readings of this table:

RSA-2048 is the current floor, not a target. It sits at 112-bit strength, which NIST’s transition guidance schedules for phase-out by 2030 and disallowance by 2035. New long-lived keys should be RSA-3072 or an elliptic curve.
RSA-4096 is not the obvious upgrade. It buys roughly 140 bits of strength for four to eight times the signing cost of RSA-3072. P-256 reaches 128 bits with a 32-byte private scalar and signs an order of magnitude faster.

Performance shape

Operation	RSA-2048	ECDSA P-256
Key generation	Slow (prime search)	Fast (one scalar multiply)
Sign / decrypt	Slow (private exponent)	Fast
Verify / encrypt	Very fast (small `e = 65537`)	Moderate
Public key size	~294 bytes (SPKI DER)	~91 bytes (SPKI DER)
Signature size	256 bytes	~64-72 bytes (DER)

RSA’s asymmetry — cheap verification, expensive signing — is why it survived so long in TLS server certificates, where a server signs once per handshake but clients verify constantly. It is also why RSA keygen in a browser can take a visible second at 4096 bits while an ECDSA keypair appears instantly.

Reading a PEM File

A PEM file is Base64-encoded DER (Distinguished Encoding Rules), the canonical binary serialisation of an ASN.1 structure, wrapped in armour lines. The header tells you exactly which structure is inside.

Header line	Structure	Contains
`-----BEGIN PUBLIC KEY-----`	SubjectPublicKeyInfo (RFC 5280)	Algorithm identifier + public key bits
`-----BEGIN PRIVATE KEY-----`	PKCS#8 PrivateKeyInfo (RFC 5958)	Algorithm identifier + private key
`-----BEGIN ENCRYPTED PRIVATE KEY-----`	PKCS#8 EncryptedPrivateKeyInfo	Passphrase-wrapped private key
`-----BEGIN RSA PRIVATE KEY-----`	PKCS#1 RSAPrivateKey (RFC 8017)	RSA parameters only, no algorithm identifier
`-----BEGIN EC PRIVATE KEY-----`	SEC1 ECPrivateKey (RFC 5915)	Curve parameters + scalar
`-----BEGIN CERTIFICATE-----`	X.509 Certificate	A signed public key — see the

The modern, algorithm-agnostic pair is PKCS#8 for private and SPKI for public; those are the two formats the Web Crypto API exports. The older PKCS#1 and SEC1 forms are algorithm-specific, which is why tooling has converged on PKCS#8.

Generating a keypair with Web Crypto

// RSA-3072 signing keypair, exported as PKCS#8 + SPKI PEM.
const { publicKey, privateKey } = await crypto.subtle.generateKey(
 {
 name: "RSASSA-PKCS1-v1_5", // or "RSA-PSS" / "RSA-OAEP" for encryption
 modulusLength: 3072,
 publicExponent: new Uint8Array([0x01, 0x00, 0x01]), // 65537
 hash: "SHA-256",
 },
 true, // extractable
 ["sign", "verify"]
);

const toPem = (der, label) => {
 const b64 = btoa(String.fromCharCode(...new Uint8Array(der)));
 return `-----BEGIN ${label}-----\n${b64.match(/.{1,64}/g).join("\n")}\n-----END ${label}-----`;
};

const privatePem = toPem(await crypto.subtle.exportKey("pkcs8", privateKey), "PRIVATE KEY");
const publicPem = toPem(await crypto.subtle.exportKey("spki", publicKey), "PUBLIC KEY");

Three details that trip people up:

publicExponent is 65537 (0x010001). It is a Fermat prime with only two set bits, making verification fast; smaller exponents such as 3 have historically enabled padding attacks in badly implemented verifiers.
Base64 lines wrap at 64 characters. Some strict parsers reject unwrapped single-line PEM.
extractable: true is required to export at all. Set it to false for keys that should stay inside the browser’s key store.

The SSH format gap

A -----BEGIN PUBLIC KEY----- block cannot be pasted into ~/.ssh/authorized_keys. OpenSSH uses its own wire encoding — an algorithm name, then length-prefixed fields, Base64-encoded onto one line:

# SPKI PEM -> OpenSSH public key line
ssh-keygen -i -m PKCS8 -f public.pem

# PKCS#8 private key -> OpenSSH private key file
ssh-keygen -p -m RFC4716 -f id_rsa

Also worth knowing: OpenSSH’s recommended key type today is Ed25519, and the Web Crypto generateKey algorithms for RSA and ECDSA do not produce it. Generate Ed25519 keys with ssh-keygen -t ed25519.

Choosing an Algorithm in 2026

Use case	Recommendation	Reasoning
New TLS server certificate	ECDSA P-256, RSA-2048/3072 as fallback	Smaller handshake; universally supported by browsers
JWT signing	ES256 (ECDSA P-256) or RS256	ES256 gives shorter tokens; see the
SSH user key	Ed25519 via `ssh-keygen`	Small, fast, no curve-parameter footguns
Legacy enterprise PKI	RSA-3072	Broadest hardware and appliance support
Encrypting data directly	Neither — use hybrid	Encrypt with , wrap the AES key with RSA-OAEP or ECDH

The RSA-OAEP Size Limit and Why Hybrid Encryption Exists

RSA does not encrypt streams. It encrypts one integer smaller than the modulus. With OAEP padding (RFC 8017) the usable plaintext is:

max plaintext bytes = k - 2 * hLen - 2

k = modulus size in bytes
hLen = hash output size in bytes

Key size	`k`	OAEP hash	Maximum plaintext
2048-bit	256 bytes	SHA-1 (20)	214 bytes
2048-bit	256 bytes	SHA-256 (32)	190 bytes
3072-bit	384 bytes	SHA-256 (32)	318 bytes
4096-bit	512 bytes	SHA-256 (32)	446 bytes

190 bytes will not hold a document, a database row, or a session payload — which is why real systems use hybrid encryption:

Generate a random AES-256 content key.
Encrypt the payload with AES-256-GCM — fast, streaming, authenticated.
Encrypt only the 32-byte AES key with RSA-OAEP (or derive it with ECDH).
Ship the wrapped key alongside the ciphertext.

That is the structure inside TLS, JWE, S/MIME, and PGP: the asymmetric half transports a key, the symmetric half does the work. See the for the symmetric side.

Signature padding: PSS or PKCS#1 v1.5?

Scheme	Status	Use when
RSA-PSS	Recommended (RFC 8017)	Any new system — randomised padding with a formal security proof
RSASSA-PKCS1-v1_5	Legacy but ubiquitous	Interoperating with existing TLS certificates and JWT `RS256`
Raw RSA, no padding	Never	Textbook RSA is deterministic and trivially malleable

Never encrypt bulk data with RSA. RSA-OAEP can encrypt at most a few hundred bytes for a given modulus. The correct pattern is hybrid encryption: generate a random symmetric key, encrypt the payload with AES-GCM, and encrypt only that symmetric key with the recipient’s public key.

Where post-quantum stands

NIST finalised three post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. FIPS 206 (FN-DSA) remains a draft as of 2026. NIST’s transition schedule phases out 112-bit-strength classical algorithms by 2030 and disallows them from 2035; NSA’s CNSA 2.0 sets 2030 for national security systems.

Shor’s algorithm on a sufficiently large quantum computer would factor RSA moduli efficiently, breaking RSA at every key size, and would solve elliptic curve discrete logarithms too. No such machine exists today, but ciphertext captured now can be stored for later decryption — the harvest now, decrypt later problem. The deployed transition path is hybrid: combine a classical key exchange with ML-KEM so the session survives if either component fails.

For an application team, the actionable version is short: do not rewrite your PKI this quarter, but stop hardcoding algorithm names, keep certificate lifetimes short so rotation is routine, and inventory where long-lived signatures and long-lived encrypted archives live — those are the assets exposed to “harvest now, decrypt later”.

Step-by-Step: Generating and Inspecting Keys with Toolbox

Open the tool: visit the .
Pick a modulus size: 2048 for legacy interoperability, 3072 for a 128-bit strength target, 4096 only when a policy demands it.
Generate: the browser’s Web Crypto implementation performs the prime search locally; nothing is sent over the network.
Copy both PEM blocks: the PKCS#8 private key and the SPKI public key. Store the private key in a secret manager immediately — a key that has been in a clipboard buffer and then an email is not a secret.
Verify the pair matches before deploying:

openssl rsa -in private.pem -pubout | diff - public.pem && echo "pair OK"
openssl rsa -in private.pem -noout -text | head -2 # confirms modulus size

Outcome: a correctly encoded, verified keypair for local development, signing tests, or PKI experiments — generated without pasting a private key into a remote web service.

Related guides: · ·

FAQ

Frequently Asked Questions

Is a 256-bit ECC key really as strong as a 3072-bit RSA key? ▼

Against classical attacks, yes. Strength is measured in equivalent symmetric bits: RSA-2048 is about 112 bits, while RSA-3072 and NIST P-256 are both about 128 bits. RSA keys must grow much faster because the general number field sieve is sub-exponential, whereas the best generic attack on elliptic curve discrete logarithms takes square-root time in the group order.

What is the difference between PKCS#8 and SPKI PEM files? ▼

PKCS#8 (RFC 5208 / RFC 5958) is the standard private-key container and starts with BEGIN PRIVATE KEY. SPKI, or SubjectPublicKeyInfo (RFC 5280), is the standard public-key container and starts with BEGIN PUBLIC KEY. Both are Base64-wrapped DER ASN.1. The older PKCS#1 form, BEGIN RSA PRIVATE KEY, carries only RSA parameters with no algorithm identifier.

Can I paste a generated PEM public key into authorized_keys for SSH? ▼

No. OpenSSH uses its own one-line format beginning with ssh-rsa, ecdsa-sha2-nistp256, or ssh-ed25519 followed by Base64 of a length-prefixed structure. Convert a SPKI PEM with ssh-keygen -i -m PKCS8 -f public.pem. Note that Ed25519, OpenSSH's preferred modern type, is not produced by the Web Crypto RSA or ECDSA algorithms.

Should I generate post-quantum keys instead of RSA or ECC today? ▼

For most TLS, SSH, and signing work RSA and ECC remain the interoperable choice in 2026. NIST finalised ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024, while FN-DSA (FIPS 206) is still draft, and NIST schedules 112-bit-strength algorithms for phase-out by 2030 and disallowance by 2035. Prioritise crypto-agility: configurable algorithms, short certificate lifetimes, and an inventory of long-lived secrets.

Rsa | Toolbox Guides & Articles

RSA vs ECC Keypairs: Key Sizes, PEM Formats, and Choosing a Curve in 2026