RSA Key Pair Generator

What is RSA?

RSA — named after Rivest, Shamir and Adleman, who published it in 1977 — is the original practical public-key cryptosystem. Its security rests on the difficulty of factoring the product of two large prime numbers: given the modulus n = p * q, recovering p and q is computationally infeasible at sufficient key sizes.

An RSA key pair has two parts: a public key anyone can hold, and a private key the owner must keep secret. The two are mathematical inverses — anything encrypted (or signed) with one can only be decrypted (or verified) with the other. Half a century later, RSA still underpins most of the public-key infrastructure you touch every day: the TLS handshake to your bank, the JWT issued by your auth provider, the GitHub SSH key in your ~/.ssh, the code-signing certificate on a Windows installer.

How it works

Key generation, in outline:

1. Pick two large random primes p and q of equal bit-length — each roughly half the desired key size.
2. Compute the modulus n = p * q and the Carmichael totient λ(n) = lcm(p−1, q−1).
3. Choose a public exponent e coprime to λ(n) — almost universally 65537 (0x10001), a small Fermat prime that permits fast public-side operations.
4. Compute the private exponent d as the modular inverse of e mod λ(n).
5. The public key is (n, e). The private key is (n, d) plus, in practice, p, q and several pre-computed CRT values that speed up signing.

The Web Crypto API does all of this inside crypto.subtle.generateKey, using the browser’s CSPRNG to source the prime candidates. The keys are then exported as PEM-encoded byte arrays: SPKI (Subject Public Key Info) for the public side and PKCS#8 for the private side, both wrapped in the familiar -----BEGIN ... KEY----- armour.

Common use cases

• TLS certificates. A web server presents a certificate that binds its hostname to its RSA public key, signed by a CA. The server proves possession of the matching private key during the TLS handshake.
• SSH login. ~/.ssh/id_rsa holds an RSA private key; the corresponding public key sits in the server’s authorized_keys. SSH signs a session-specific challenge to prove possession.
• JWT signing. RS256, RS384 and RS512 JWTs are signed with RSA private keys and verified with the matching public key — ideal for issuing tokens that any consumer can verify without sharing a secret.
• Code signing. Windows Authenticode, macOS notarisation, npm package signing and Java JAR signing all use RSA (and ECDSA) signatures to prove publisher identity.
• Document signing. PDF signatures, S/MIME emails and XML-DSig workflows still rely heavily on RSA.

How to use this RSA key pair generator

1. Choose a key size — 2048 is the sensible default; 3072 or 4096 if you need a longer lifetime; 1024 only for compatibility with legacy systems you cannot change.
2. Click Generate key pair. Generation runs in your browser via crypto.subtle.generateKey; expect 1–3 seconds for 2048 bits and noticeably longer for 4096.
3. Copy the public key (-----BEGIN PUBLIC KEY----- block) to wherever the relying party needs it — a server config, a JWT verifier, a CA’s CSR form.
4. Copy the private key (-----BEGIN PRIVATE KEY----- block) into a secure store. Do not paste it into chat, tickets, or any service you don’t control.
5. If you only need one half — for example you’re generating a JWT verifier and the issuer already holds the private side — discard the other half and clear the page.

Security considerations

• Key size for longevity. A 2048-bit key is fine for short-lived TLS certificates (90-day Let’s Encrypt rotation); a 3072- or 4096-bit key is the right pick for keys you may keep for years.
• Never reuse a key across roles. Use distinct keys for TLS, signing JWTs, signing code, and SSH. Compromise of one role should not pivot into another.
• Rotate on schedule. Even with good hygiene, plan rotation: yearly for TLS, every 2–3 years for SSH, on every release for ephemeral signing keys.
• The private key is the asset. A leaked private key is catastrophic; treat it as more sensitive than the password it protects. Filesystem permissions alone are not enough — encrypt at rest where the platform supports it.
• Consider ECC. For new systems, an ECDSA P-256 or Ed25519 key gives equivalent security at a fraction of the size and is faster to sign with. RSA remains right when interoperability with older systems is required.

Privacy

Both keys are generated by crypto.subtle.generateKey in your browser, exported to PEM locally with crypto.subtle.exportKey, and displayed on this page. No network request is made during generation. You can verify in the Network tab — after the initial JavaScript bundle there is silence — or pull the cable after the page loads and the generator continues to work.

Compatibility notes

The PEM-encoded output uses the standard SPKI (public) and PKCS#8 (private) ASN.1 structures and is accepted by OpenSSL, Node.js crypto, Python cryptography, Java KeyFactory, Go’s crypto/x509, .NET RSA.ImportFromPem, the jose and jsonwebtoken libraries, and every TLS toolchain. To convert to OpenSSH format (ssh-rsa AAAA...), run ssh-keygen -i -f key.pub -m PKCS8. The generator requires Web Crypto API support, present in every browser released since 2018.