Understanding RSA Key Pairs: Key Sizes, PEM Formats, and When to Use RSA
RSA is public-key cryptography with two distinct keys: what one locks, only the other opens. That yields two uses — encrypt with the public key and decrypt with the private one for confidentiality, or sign with the private key and verify with the public one for authenticity. This tool generates key pairs using the browser's Web Crypto API.
Choosing a key size
2048-bit is the working default. 4096-bit is stronger but not free: generation takes noticeably longer, sign and verify operations cost more, and the signatures themselves get bigger. A service verifying thousands of tokens per second will feel that as real latency. Conversely, for a root key you touch once every few years, 4096-bit is a sensible choice.
| Key size | Symmetric-equivalent strength | Status | Use for |
|---|---|---|---|
| 1024-bit | ~80 bits | Inadequate | Never for new work |
| 2048-bit | ~112 bits | Current standard | Most TLS certificates, JWT signing |
| 3072-bit | ~128 bits | Comfortable margin | Signatures that must last many years |
| 4096-bit | ~152 bits | Conservative | Root CAs, very long-lived keys |
How to use it
- Pick a key size. Choose 2048-bit unless you have a specific reason not to.
- Press generate. A 4096-bit pair can take several seconds in the browser.
- Distribute the public key to whoever needs to verify or encrypt. It's safe to publish.
- Never share the private key. If it leaks, revoke it and issue a new pair immediately.
Identifying formats by PEM header
A PEM file is a Base64-encoded key wrapped in human-readable header lines. The header alone tells you the format, which matters because many libraries accept only one of them.
# extract the public key from a private key openssl rsa -in private.pem -pubout -out public.pem # convert PKCS#1 to PKCS#8 openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem # inspect key details (size, exponent, ...) openssl rsa -in private.pem -text -noout
| Header | Format | Notes |
|---|---|---|
| BEGIN PUBLIC KEY | SPKI (X.509) | Generic public key including algorithm info |
| BEGIN RSA PUBLIC KEY | PKCS#1 | RSA-specific public key |
| BEGIN PRIVATE KEY | PKCS#8 | Generic private key including algorithm info — preferred today |
| BEGIN RSA PRIVATE KEY | PKCS#1 | RSA-specific private key, common in legacy tooling |
| BEGIN ENCRYPTED PRIVATE KEY | PKCS#8, encrypted | Passphrase-protected private key |
| BEGIN OPENSSH PRIVATE KEY | OpenSSH | SSH-specific, produced by ssh-keygen |
When not to reach for RSA
Trying to encrypt bulk data directly with RSA is a mistake. RSA can only process data shorter than its key, so a 2048-bit key with OAEP padding encrypts roughly 190 bytes of plaintext. To encrypt a file you use a hybrid scheme: encrypt the data with a symmetric cipher like AES and wrap only the AES key with RSA. That's exactly how TLS works.
For signing in a new system, elliptic curves (Ed25519, ECDSA P-256) are usually the better choice: much shorter keys and signatures at equivalent strength, and faster operations. An Ed25519 public key is 32 bytes where a 2048-bit RSA public key is 256. The main reason to pick RSA today is compatibility — the other side accepts nothing else.
Common uses
- Signing JWTs with RS256 so several services can verify with a public key
- SSH public key authentication (though ssh-keygen -t ed25519 is now preferred)
- Generating a CSR to obtain a TLS certificate
- Signing packages or release artifacts to guarantee distribution integrity
- Verifying signatures on data exchanged between separate organizations
Storing private keys
A private key is a value whose exposure collapses everything it protected. Not committing it is table stakes — and note that adding it to .gitignore doesn't help if it's already in the history. In production, the safest arrangement is a cloud KMS or HashiCorp Vault, which performs signing on your behalf without ever releasing the key. At minimum, restrict file permissions to 600 and store it as passphrase-protected PKCS#8.
Frequently Asked Questions
- Are the generated keys sent to a server?
- No — the browser's Web Crypto API generates them locally. Even so, a browser-generated key isn't a good choice for a long-lived production private key: extensions, clipboard access, and other factors are hard to control there. Use this for learning and testing, and generate production keys on a server or in a KMS.
- Can someone derive the private key from the public key?
- Not in any realistic timeframe. RSA's security rests on the difficulty of factoring large numbers, and factoring a 2048-bit modulus is out of reach for existing computing resources. A sufficiently capable quantum computer would break that assumption via Shor's algorithm, which is why post-quantum migration is under active discussion.
- Can I recover a lost key pair?
- A lost private key is unrecoverable. Data encrypted to it can never be opened, and any system that authenticated with it needs a new key registered. Losing only the public key is harmless, since it can always be re-extracted from the private key.
- Can I use this directly with SSH?
- Not without conversion. SSH's authorized_keys uses a single-line 'ssh-rsa AAAAB3Nza...' form rather than PEM. You can convert with ssh-keygen -i -m PKCS8 -f public.pem, but if the goal is a new SSH key, ssh-keygen -t ed25519 is simpler and the recommended approach.
- What does the public exponent 65537 mean?
- An RSA public key is a modulus plus a public exponent, and that exponent is almost always 65537. Being 2^16+1, it has only two set bits, which makes encryption and verification fast, while still being large enough to avoid the attacks that afflict very small exponents like 3. There's no reason to change it.
- My PEM file lost its line breaks — is that a problem?
- Yes. Many parsers assume the header, body, and footer are on separate lines. A frequent failure is storing a PEM in an environment variable where the newlines become literal \n sequences. Either restore them after reading with replace(/\\n/g, "\n"), or Base64-encode the whole PEM so it stores safely as one line.
💡 Note: If you accidentally commit a private key, deleting it from history isn't enough. An exposed key must be revoked and replaced — that's the only reliable remedy.