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

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.

Two practical readings of this table:

1. 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.
2. 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

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.

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

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

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

1. Generate a random AES-256 content key.
2. Encrypt the payload with AES-256-GCM — fast, streaming, authenticated.
3. Encrypt only the 32-byte AES key with RSA-OAEP (or derive it with ECDH).
4. 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 AES-256-GCM guide for the symmetric side.

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

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

1. Open the tool: visit the Toolbox RSA Keypair Generator.
2. Pick a modulus size: 2048 for legacy interoperability, 3072 for a 128-bit strength target, 4096 only when a policy demands it.
3. Generate: the browser’s Web Crypto implementation performs the prime search locally; nothing is sent over the network.
4. 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.
5. 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: X.509 certificate anatomy · AES-256-GCM encryption · HMAC signature verification