RSA Key Pair Generation in Your Browser
This tool generates RSA key pairs using the Web Crypto API built into your browser. No data leaves your device - the keys are created entirely client-side using cryptographically secure randomness provided by your operating system's CSPRNG. I have used this approach in production deployments and the output is identical to what openssl genrsa produces - standard PKCS#8 private keys and SPKI public keys that work everywhere.
RSA Encryption vs Signing
RSA serves two distinct purposes, and the choice matters because the underlying algorithms are different.
Encryption (RSA-OAEP) lets anyone encrypt a message with your public key that only you can decrypt with your private key. This is used for key exchange in TLS handshakes, encrypting session keys, and protecting small payloads. RSA-OAEP replaced the older PKCS#1 v1.5 padding scheme because OAEP is provably secure against chosen-ciphertext attacks - if you see code still using RSA/ECB/PKCS1Padding, that is a vulnerability.
Signing (RSASSA-PKCS1-v1_5) lets you create a digital signature with your private key that anyone can verify with your public key. This is the foundation of TLS certificates, code signing, JWT tokens with RS256/RS384/RS512 algorithms, and package verification (npm, apt, RPM). The verifier only needs your public key, which can be distributed freely.
How RSA Key Generation Works
RSA key generation follows a well-defined mathematical process. The algorithm selects two large prime numbers p and q, computes their product n = p × q (the modulus), and derives the public exponent e (almost always 65537, which is 0x10001 - the value you see in JWK output) and the private exponent d from Euler's totient. The security of RSA rests entirely on the fact that factoring n back into p and q is computationally infeasible for sufficiently large keys.
The Web Crypto API delegates this to your browser's native cryptography implementation (BoringSSL in Chrome, NSS in Firefox), which uses the same battle-tested code that powers TLS connections. The crypto.subtle.generateKey() call is asynchronous because prime generation involves probabilistic primality testing (Miller-Rabin) which can take hundreds of milliseconds for 4096-bit keys.
Choosing a Key Size
Key size directly determines security strength and performance. Here is how the options compare in practice:
| Key Size | Security Bits | Generation Time | Recommended Until | Use Case |
|---|---|---|---|---|
| 2048-bit | ~112 | ~100-300ms | 2030 | General purpose, short-lived tokens, development |
| 3072-bit | ~128 | ~300-800ms | 2030+ | New projects, compliance requirements (NIST SP 800-57) |
| 4096-bit | ~140 | ~1-3s | 2030+ | Root CAs, long-lived signing keys, high-security environments |
NIST SP 800-57 recommends 2048-bit as the minimum through 2030. The French ANSSI and German BSI already recommend 3072-bit for new deployments. If you are setting up infrastructure that will be in use for more than five years, 3072-bit is the pragmatic choice - it provides 128-bit equivalent security (the same level as AES-128) with acceptable performance overhead.
PEM vs JWK Format
PEM (Privacy-Enhanced Mail) is the traditional format used since the 1990s. It wraps DER-encoded ASN.1 binary data in Base64 with -----BEGIN/END----- header lines. PEM is the format expected by OpenSSL, SSH (~/.ssh/id_rsa), TLS certificate files (.pem, .crt, .key), nginx, Apache, and virtually every server-side tool.
JWK (JSON Web Key, RFC 7517) is the web-native format. It represents key components as Base64url-encoded JSON fields. JWK is used in OAuth 2.0 JWKS endpoints (/.well-known/jwks.json), OpenID Connect discovery, JWT libraries, and browser-based cryptography. If you are building a web API that publishes public keys for token verification, JWK is the right choice.
Both formats represent the same mathematical key - you can convert between them freely. This tool exports both simultaneously so you can use whichever your toolchain requires.
Hash Algorithm Selection
The hash algorithm is used internally during RSA operations - for signing, it hashes the message before applying the RSA private key operation; for encryption with OAEP, it is used in the padding scheme. SHA-256 is the default and correct choice for most applications. SHA-384 and SHA-512 provide larger hash outputs but do not meaningfully increase security for typical RSA key sizes - the key size is the binding constraint, not the hash. Use SHA-256 unless a specific protocol or compliance requirement mandates otherwise.
Common Use Cases
- JWT RS256 signing - generate a key pair, use the private key to sign tokens on your server, publish the public key at your JWKS endpoint for clients to verify
- TLS/SSL certificates - generate a private key, create a CSR (Certificate Signing Request) from it, submit to a CA. The PEM output from this tool is directly usable with
openssl req -new -key private.pem - SSH authentication - while Ed25519 is preferred for new SSH keys, RSA keys are still widely used and required by some legacy systems
- Code and package signing - sign release artefacts with your private key so users can verify authenticity with your public key
- Encrypted configuration - encrypt secrets with the public key during CI/CD, decrypt with the private key at runtime
Security Best Practices
Generating the key pair is the easy part. Keeping the private key safe is where most teams fail. Here is what matters:
- Never commit private keys to version control. Use environment variables, secret managers (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager), or encrypted configuration files.
- Rotate keys on a schedule. For JWT signing keys, annual rotation is common. For TLS certificates, Let's Encrypt enforces 90-day lifetimes for good reason.
- Use the smallest key that meets your requirements. 4096-bit keys are slower for every operation - signing, verification, handshake. Do not use them unless you have a concrete reason.
- Consider alternatives for new projects. For signing, Ed25519 (EdDSA) offers equivalent security with 256-bit keys and much faster operations. For key exchange, X25519 (ECDH) has largely replaced RSA in modern TLS. RSA remains essential for compatibility with existing infrastructure.
RSA vs Elliptic Curve Cryptography
RSA and ECC (Elliptic Curve Cryptography) both provide asymmetric encryption and signing, but they differ significantly in key size and performance:
| Property | RSA | ECC (P-256 / Ed25519) |
|---|---|---|
| Key size for 128-bit security | 3072 bits | 256 bits |
| Signature size | 384 bytes (3072-bit) | 64 bytes |
| Sign performance | Slower | Much faster |
| Verify performance | Very fast | Faster |
| Ecosystem support | Universal | Broad but some legacy gaps |
| Best for | Compatibility, TLS certs, legacy systems | New projects, mobile, IoT, SSH |
For new projects with no legacy constraints, ECC (specifically Ed25519 for signing and X25519 for key exchange) is the better choice. RSA remains the right tool when you need broad compatibility - particularly with older Java versions, embedded devices, hardware security modules, and enterprise systems that have not adopted ECC.
How This Tool Generates Keys
Under the hood, this tool calls crypto.subtle.generateKey() with your selected algorithm, key size, and hash. The browser delegates to its native crypto library (BoringSSL in Chromium, NSS in Firefox) which generates two large primes, computes the modulus and exponents, and returns a CryptoKeyPair object. The keys are then exported in two formats simultaneously: SPKI (Subject Public Key Info) and PKCS#8 for PEM, and JWK for the JSON format. The PEM conversion wraps the raw binary export in Base64 with 64-character line breaks and the standard header/footer lines. No data is transmitted - everything happens in your browser's JavaScript runtime.