RSA Key Pair Generator

About RSA Key Pair Generator

How RSA Key Generation Works

RSA key generation involves finding two large prime numbers (p and q), multiplying them to get the modulus (n = p x q), and computing the public and private exponents from Euler's totient. The security relies on the fact that factoring n back into p and q is computationally infeasible for large key sizes.

Step	What Happens	Result
1. Generate primes	Two random primes p and q are found	Each prime is half the key size (e.g., 1024 bits for a 2048-bit key)
2. Compute modulus	n = p x q	This becomes part of both the public and private key
3. Compute totient	phi(n) = (p-1)(q-1)	Used to derive the private exponent
4. Choose public exponent	e = 65537 (standard)	Used for encryption and signature verification
5. Compute private exponent	d = e^(-1) mod phi(n)	Used for decryption and signing - this is the secret

The public key contains (n, e) and can be shared freely. The private key contains (n, d) and must be kept secret. Finding d from e and n alone requires factoring n, which is the hard mathematical problem that secures RSA.

Key Size Comparison

Key Size	Security Level (bits)	Generation Time (browser)	Status	Use Case
1024-bit	~80 bits	Near-instant	Insecure - do not use in production	Testing and education only
2048-bit	~112 bits	~0.5 seconds	Current minimum standard	TLS certs, SSH keys, most applications
3072-bit	~128 bits	~2 seconds	Recommended by NIST for 2031+	Long-lived keys, government systems
4096-bit	~140 bits	~5-15 seconds	Strong - good margin of safety	Root CA certificates, high-security applications

NIST recommends a minimum of 2048-bit RSA for current use and 3072-bit for protection beyond 2030. The "security level" represents the equivalent symmetric key strength - a 2048-bit RSA key provides roughly the same protection as a 112-bit symmetric key.

PEM Output Format

The tool outputs keys in PEM (Privacy Enhanced Mail) format, the most widely supported text encoding for cryptographic keys.

Key Type	Encoding	PEM Header	Compatible With
Public key	SPKI (Subject Public Key Info)	-----BEGIN PUBLIC KEY-----	OpenSSL, Node.js, Python, Go, Java, most cloud services
Private key	PKCS#8	-----BEGIN PRIVATE KEY-----	OpenSSL, Node.js, Python, Go, Java, AWS KMS, GCP KMS

PEM files contain Base64-encoded DER (binary) data wrapped in human-readable headers. You can convert between PEM and DER formats using OpenSSL if a service requires a different format.

Where RSA Keys Are Used

Application	Typical Key Size	What the Key Does
TLS/SSL certificates	2048-bit	Server proves its identity to browsers during HTTPS handshake
SSH authentication	2048-4096-bit	User proves identity to server without a password (ssh-keygen -t rsa)
JWT signing (RS256)	2048-bit	Server signs tokens with private key, anyone can verify with public key
Code signing	2048-4096-bit	Developer signs software to prove it has not been tampered with
PGP/GPG email	2048-4096-bit	Sender encrypts email with recipient's public key
Package signing (npm, apt)	2048-4096-bit	Repository signs packages to prevent supply-chain attacks

RSA vs Other Asymmetric Algorithms

Algorithm	Key Size for 128-bit Security	Performance	Status
RSA	3072-bit	Slow key gen, moderate sign/verify	Ubiquitous, gradually being replaced by ECC for new systems
ECDSA (P-256)	256-bit	Fast key gen, fast sign/verify	Default for new TLS certs, GitHub SSH keys
Ed25519	256-bit	Very fast, constant-time	Preferred for SSH, emerging in TLS
DSA	3072-bit	Similar to RSA	Deprecated - removed from OpenSSH 7.0+

Elliptic curve keys (ECDSA, Ed25519) achieve the same security as RSA with much smaller keys - a 256-bit EC key is as strong as a 3072-bit RSA key. EC keys are faster to generate and produce smaller signatures. For new systems, Ed25519 is generally preferred over RSA. However, RSA remains necessary for backwards compatibility with many existing systems.

OpenSSL Equivalents

Task	OpenSSL Command
Generate 2048-bit key pair	openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048
Extract public key	openssl pkey -in private.pem -pubout -out public.pem
View key details	openssl pkey -in private.pem -text -noout
Convert PEM to DER	openssl pkey -in private.pem -outform DER -out private.der

For production deployments, generating keys on a server or local machine using OpenSSL is recommended over browser-based generation. The Web Crypto API uses a cryptographically secure random number generator, but server-side tools offer better control over key storage and access permissions.

For symmetric encryption with a password, the Encryption Tool uses AES-256-GCM. For keyed message signing without encryption, the HMAC Generator creates message authentication codes. All key generation runs entirely in your browser via the Web Crypto API.

What Is the Post-Quantum Deprecation Timeline?

NIST has set a 2030 deadline to deprecate RSA-2048 and ECC-256, with a full ban by 2035. New keys generated today should either be sized for 128-bit security (3072-bit RSA or higher) or plan for a migration to post-quantum algorithms before 2030. The three NIST-standardised post-quantum algorithms published in FIPS 203, 204, and 205 are ML-KEM (key encapsulation), ML-DSA (digital signatures), and SLH-DSA (hash-based signatures). None of them are drop-in replacements for RSA - they have larger keys, larger signatures, and different performance characteristics.

Year	NIST Guidance	CNSA 2.0 (US National Security)
2026	RSA-2048 acceptable for new data protection	CNSA 2.0 preferred for code and firmware signing
2030	RSA-2048 deprecated for new data; 3072-bit minimum for 128-bit security	Post-quantum algorithms mandatory for code signing
2035	RSA-2048 and ECC-256 disallowed for new systems	Full post-quantum transition required for NSS

For long-lived keys (root certificate authorities, code-signing roots, document archives) the "harvest now, decrypt later" risk already applies: an attacker capturing encrypted traffic today could decrypt it once a large quantum computer is built. Short-lived TLS session keys and ephemeral JWT signing keys are less exposed because the secrets protected have limited value by 2030.

Why Is 65537 the Standard Public Exponent?

The public exponent e = 65537 (0x10001 in hex, the fifth Fermat prime) is used by nearly every RSA implementation, including OpenSSL, the Web Crypto API, Java's JCA, and Microsoft CryptoAPI. It hits a balance between security and performance that no other small number achieves. Because 65537 has only two bits set (binary 10000000000000001), the square-and-multiply exponentiation used for encryption and signature verification runs in just 17 multiplications. A smaller exponent like e = 3 is faster but has been linked to attacks when combined with poor padding (Bleichenbacher's 2006 signature forgery against PKCS#1 v1.5), so most libraries reject it. A larger exponent adds no security benefit and slows every verification.

Worked example: Verifying a 2048-bit RSA signature with e = 65537 requires 17 modular multiplications on 2048-bit numbers. With e = 3 it would take 2 multiplications (50x faster), but the exponent is too small to hide the plaintext padding reliably. With a random 2048-bit e the worst case would be ~3,000 multiplications, making every TLS handshake noticeably slower. 65537 is the sweet spot.

Common Mistakes When Using RSA Keys

The most frequent RSA implementation errors do not involve breaking the maths - they involve misusing keys or using the wrong padding scheme.

• Encrypting large data directly with RSA. RSA can only encrypt messages smaller than the modulus minus padding overhead (around 190 bytes for a 2048-bit key with OAEP). For real data, generate a random AES-256 key, encrypt the data with AES-GCM, then encrypt the AES key with the recipient's RSA public key. This is "hybrid encryption" and is how every real system (TLS, PGP, JWE) uses RSA.
• Reusing the same key for signing and encryption. Best practice is one key per purpose. Many CA policies and standards (JWS/JWE, X.509 key usage extensions) require separate keys, because signing and encryption have different threat models and key rotation cadences.
• Shipping PKCS#1 v1.5 padding for new systems. PKCS#1 v1.5 is still used for RSA signatures but has a long history of padding-oracle attacks (Bleichenbacher, Manger, ROBOT). Use RSA-OAEP for encryption and RSA-PSS for signatures in new systems. The Web Crypto API supports both.
• Storing private keys in plain text. A private PEM file on disk is as sensitive as a password. Store it with restrictive permissions (chmod 600 on Linux), wrap it with a passphrase, or keep it in a hardware security module or cloud KMS. Leaked private keys have caused high-profile incidents including the 2015 Juniper ScreenOS backdoor and the 2023 Storm-0558 Microsoft key theft.
• Using a 1024-bit key because it "worked last time". 1024-bit RSA was deprecated by NIST in 2013. Factoring a 1024-bit key is estimated to cost in the low millions of dollars for a well-resourced attacker, and some academic efforts have already factored keys close to this size. Never use 1024-bit for anything real.

If you need a password-derived symmetric key for file encryption instead of asymmetric cryptography, see the password generator and pair it with the Encryption Tool. For server-side bcrypt password hashing, the bcrypt generator produces the same output format as most web frameworks.

Sources

• NIST SP 800-57 Part 1 Rev. 5 - Recommendation for Key Management
• NIST SP 800-131A Rev. 2 - Transitioning Cryptographic Algorithms and Key Lengths
• NIST IR 8547 - Transition to Post-Quantum Cryptography Standards
• NSA CNSA 2.0 Algorithms and Timeline
• MDN - SubtleCrypto.generateKey()
• RFC 8017 - PKCS #1: RSA Cryptography Specifications v2.2
• RFC 5208 - PKCS #8 Private-Key Information Syntax