RSA keypairs: sizes and PEM

RSA is still the workhorse asymmetric algorithm for TLS certificates, SSH host keys, JWT signing (RS256), and many “encrypt with public key / decrypt with private key” workflows. You generate a keypair: a public key you can share, and a private key you must protect. Strength comes mainly from the modulus length (bit size of n); interoperability often comes down to how you export the key—usually as PEM.

This guide covers modulus sizes people actually ship, which Web Crypto algorithm names map to encryption vs signing, what PKCS#8 and SPKI PEM look like, and why generating keys in the browser keeps private material off upload-happy “key generator” sites.

Public and private in one sentence

RSA’s public key is essentially a large modulus n and a public exponent e (almost always 65537). The private key holds the factors (or equivalent private exponents) that let you decrypt or sign. Anyone with the public key can encrypt to you or verify your signatures; only the private key holder can decrypt or produce valid signatures.

Unlike AES-GCM, RSA is not a bulk cipher for large files. Typical uses:

Job	Pattern
Encrypt a small secret	RSA-OAEP of a random AES key, then AES for the payload (hybrid encryption)
Sign data	Hash the message, then RSA signature (PKCS#1 v1.5 or PSS)
Certificates / SSH	Bind identity to a public key; private key stays offline or in an HSM

Modulus size: 2048, 3072, or 4096?

Bit length is the size of n. Larger moduli resist factoring longer, but generation and every crypto operation get slower—especially in browsers.

Bits	Typical guidance	Trade-off
2048	Default for many new certs and APIs today	Fast enough; widely accepted
3072	Extra margin when policy asks “above 2048”	Noticeably slower generate/sign
4096	High-assurance / long-lived roots, or explicit requirements	Slowest; 4096-bit generate can stall a tab for seconds

Industry guidance (NIST and common CA practice) has treated 2048 as the minimum for general use for years, with larger sizes for higher security margins or longer lifetimes. Do not invent 1024-bit keys for new systems—those are obsolete.

LocalTools’ RSA Key Generator offers 2048 / 3072 / 4096 via Web Crypto. Prefer 2048 unless you have a written reason for larger; use 4096 when a checklist or CA policy demands it and you can wait for generation.

Algorithm usage: OAEP, PKCS#1 v1.5, PSS

Web Crypto (and LocalTools) does not export a bare “RSA key” without a usage. You pick how the key will be used:

Algorithm	Direction	Notes
RSA-OAEP	Encrypt / decrypt	Preferred padding for encryption; pairs with a hash (here SHA-256)
RSASSA-PKCS1-v1_5	Sign / verify	Classic signature padding; still common (RS256-style stacks)
RSA-PSS	Sign / verify	Modern probabilistic signatures; prefer when both sides support it

All three options in the local tool use SHA-256. Matching matters: a key generated for OAEP is for encryption workflows; a PKCS#1 or PSS key is for signatures. Importing the PEM into another library usually requires the same algorithm family and hash.

What PEM actually is

PEM is a text wrapper around binary DER (ASN.1):

-----BEGIN PRIVATE KEY-----
MIIE...base64...
-----END PRIVATE KEY-----

Label you often see	Meaning
BEGIN PRIVATE KEY	PKCS#8 private key (algorithm + key material)
BEGIN PUBLIC KEY	SPKI (SubjectPublicKeyInfo) public key
BEGIN RSA PRIVATE KEY	Older PKCS#1 RSA-only private encoding
BEGIN CERTIFICATE	X.509 certificate (not a raw keypair)

LocalTools exports:

• Private: PKCS#8 PEM (BEGIN PRIVATE KEY)
• Public: SPKI PEM (BEGIN PUBLIC KEY)

That pair is what most modern APIs, openssl, and Web Crypto importKey expect for “unencrypted PEM key files.” Encrypted PEM (BEGIN ENCRYPTED PRIVATE KEY) and OpenSSH formats are separate stories.

To inspect labels, Base64 length, and decoded DER size without uploading, paste into the PEM Decoder. For CSRs and self-signed certs built on similar keys, see PKI Certificate Studio.

Generating keys without uploading them

A private RSA key is long-lived authority: anyone who obtains it can decrypt or forge signatures for that identity. Prefer:

1. Web Crypto generateKey in your own tab (or a known-good CLI / HSM).
2. No POST of PEM to a third-party “online RSA generator.”
3. Clear the private key from the page when done; never commit production private keys to git.

The RSA Key Generator runs entirely in-tab: choose OAEP / PKCS#1 / PSS and modulus length, generate, then copy or download public and private PEM. Key material never leaves the device.

Common pitfalls

• Wrong size for the policy — “we require 4096” fails audits if you ship 2048; the reverse wastes CPU for no compliance gain.
• Encryption key used for signing (or the reverse) — algorithm usages are not interchangeable in Web Crypto.
• Mixing PEM dialects — PKCS#1 RSA PRIVATE KEY vs PKCS#8 PRIVATE KEY breaks naive importers.
• Pasting private PEM into tickets or chat — treat it like a password; rotate if exposed.
• Assuming RSA alone encrypts large files — use hybrid encryption (RSA wraps an AES key); see AES-GCM basics.

Try it in the browser

Use the RSA Key Generator to:

1. Pick RSA-OAEP or a signature algorithm and a modulus (start with 2048).
2. Generate a keypair and copy the SPKI public PEM and PKCS#8 private PEM.
3. Paste both into the PEM Decoder to confirm labels and DER sizes, then clear the private key from the page.

Related reading: Why “local only” matters for developer tools for the privacy model, AES-GCM basics (nonce, tag, AAD) for the symmetric half of hybrid encryption, and Generating passwords and tokens in the browser for CSPRNG habits that also apply to key material hygiene.