How to use
Pick the key size (2048, 3072, or 4096 bits) and the private key format (PKCS#1 — the historical OpenSSH default — or PKCS#8 — the modern interoperable default). Click Generate and a public key, a private key, and a SHA-256 fingerprint appear. The private key stays hidden behind a "reveal" toggle so a colleague looking over your shoulder cannot grab it from a screen share. Both keys are PEM-encoded — the `-----BEGIN ... KEY-----` block format every TLS tool, SSH client, and JWT library accepts.
Reach for this for non-production scenarios: a JWT HS256 → RS256 migration test, signing a test webhook, an SSH key for a throwaway VM, or learning how RSA-encrypted payloads round-trip. Production keys belong on the machine that will use them: `openssl genrsa -out key.pem 4096` for one-off generation, `ssh-keygen -t rsa -b 4096` for SSH, or a hardware HSM / KMS for high-value keys. The browser side of this tool uses `node-forge` and runs RSA key generation locally — the private key never touches a server — but a CSPRNG running inside a web page is harder to audit than one running in OpenSSL on a hardened machine.
Examples
Default 2048-bit, PKCS#8
Input
size: 2048
format: PKCS#8
Output
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
-----END PUBLIC KEY-----
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSk...
-----END PRIVATE KEY-----
Fingerprint: 9b:3a:...:ef:cd
2048-bit is the current floor NIST allows through 2030 for non-classified use. The PKCS#8 wrapper (`BEGIN PRIVATE KEY`, not `BEGIN RSA PRIVATE KEY`) lets the same key work in OpenSSL, Java keystores, .NET, and most JWT libraries without conversion. The fingerprint is a SHA-256 over the SPKI-encoded public key; useful for confirming "this is the key I generated" out-of-band before pinning it somewhere.
4096-bit for long-lived signing key
Input
size: 4096
format: PKCS#1
Output
-----BEGIN RSA PUBLIC KEY-----
...
-----END RSA PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
For keys that will be in production for 5+ years (signing CA roots, long-lived JWT issuers), 4096-bit is the conservative choice — NIST estimates 2048-bit equivalence to 112-bit symmetric and 4096-bit to 152-bit symmetric, which buys you several decades of margin against algorithmic improvement. PKCS#1 (the `RSA PRIVATE KEY` form) is what older OpenSSH versions emit and what some embedded TLS stacks expect. Modern stacks accept both formats; pick PKCS#8 if you have a choice.
PKCS#1 ↔ PKCS#8 conversion
Input
# convert PKCS#1 → PKCS#8
openssl pkcs8 -topk8 -nocrypt \
-in key-pkcs1.pem \
-out key-pkcs8.pem
# the other direction
openssl rsa \
-in key-pkcs8.pem \
-out key-pkcs1.pem -traditional
Output
(same key, different wrapper bytes — fingerprint stays identical)
If you already have a key in one format and need the other, OpenSSL converts in either direction without regenerating. The fingerprint of the SPKI-encoded public key stays the same across formats — only the *wrapping* of the private key changes. The corresponding public key (`BEGIN PUBLIC KEY` for both) is identical bytes either way.
FAQ
How big should the key be?
NIST SP 800-57 Part 1 Rev 5 (2020) gives target validity periods: **2048-bit** is acceptable for protection through 2030 (112-bit symmetric equivalent), **3072-bit** through 2030 and beyond (128-bit equivalent), **4096-bit** for high-value or long-lived keys (152-bit equivalent). For JWT signing or short-lived TLS, 2048 is fine. For an SSH key you carry between jobs for ten years, or a CA root, prefer 3072 or 4096. The cost is verification speed — 4096-bit signature verification is ~4× slower than 2048-bit, which adds up if every API call validates a JWT.
RSA vs ECDSA vs Ed25519 — which should I pick?
For new code where you control both sides, **Ed25519** is the default — smaller keys (32 bytes), faster signing and verification, immune to the implementation pitfalls (nonce reuse) that have broken ECDSA deployments. **ECDSA P-256** is the second choice when you need NIST/FIPS-compliance and Ed25519 is not approved. **RSA** wins on legacy compatibility — older TLS clients, hardware tokens, JWT JWKs published by older OAuth providers, almost every TLS certificate chain — and on the operational simplicity of "everyone knows what to do with it". Use RSA when interoperability dictates; reach for Ed25519 when you have free choice.
Can I use the same key for signing AND encryption?
Mechanically yes — RSA supports both. Cryptographically and operationally no: best practice (NIST SP 800-57 Part 1 §5.6.3) is one key per purpose. Mixing signing and encryption with the same key broadens the attack surface — a vulnerability in the signing protocol can leak information about the decryption key, and vice versa. JWT JWKs explicitly carry a `use` field (`sig` or `enc`) for this reason. For new keys, generate two and label them.
Is the browser-generated key safe enough for real use?
Use it for low-stakes scenarios: test JWT signing, an SSH key for a throwaway VM, a temporary CA for a CI test. The CSPRNG that `node-forge` (or the browser's WebCrypto fallback) uses is cryptographically sound — `crypto.getRandomValues` is what the spec mandates. The risk is not the math; it is the surrounding environment. A compromised browser extension, a network MITM that injects modified script, or a logged screen-capture session can leak the private key in ways `openssl genrsa` on an air-gapped or hardened machine cannot. For anything truly valuable, generate on the target machine and never let the private bytes leave.
I need an SSH key — can I just paste the output into `authorized_keys`?
Not directly. `authorized_keys` wants the OpenSSH wire format (`ssh-rsa AAAAB3NzaC1yc2E... user@host`), not PEM. To convert: save the public PEM to `key.pem`, then run `ssh-keygen -y -f key.pem > key.pub` (which derives the OpenSSH form from the private key) or use `ssh-keygen -i -m PKCS8 -f key.pem` on the PEM public key. For real SSH use, generate directly with `ssh-keygen -t rsa -b 4096` — it produces both PEM private key and OpenSSH public key in one shot.
Should I add a passphrase to the private key?
For local keys that sit on a laptop, yes — a passphrase encrypts the PEM bytes so casual disk-stealing or filesystem-backup leakage does not directly hand over the key. For service keys on a server where automated processes need to load them at boot, no — the passphrase has to live somewhere readable to the same process, defeating the point. This tool generates unencrypted keys; if you need a passphrase, run `openssl rsa -aes256 -in plain.pem -out encrypted.pem` after copying out.
Related concepts
RSA (Rivest–Shamir–Adleman, 1977, paper published 1978) is an asymmetric cryptosystem where the same key pair handles signing and encryption. The security rests on the difficulty of factoring the product of two large primes — a 2048-bit RSA key is the product of two ~1024-bit primes, and factoring it is currently infeasible. The public key is `(n, e)` where `e` is almost always 65537; the private key holds `d` such that `e·d ≡ 1 (mod φ(n))`. Most RSA operations are modular exponentiation; the asymmetry comes from how hard it is to derive `d` from `(n, e)` without knowing the factorization.
Two distinct **on-the-wire formats** exist for the same RSA private key. **PKCS#1** (`BEGIN RSA PRIVATE KEY`) is the original RSA-specific ASN.1 structure with fields like `modulus`, `publicExponent`, `privateExponent`. **PKCS#8** (`BEGIN PRIVATE KEY`) wraps a PKCS#1 (or other algorithm) blob in an algorithm-agnostic envelope. PKCS#8 is the modern default — same key file format works for RSA, ECDSA, Ed25519 — and is what OpenSSL emits by default since the late 2010s. Conversion does not regenerate the key; only the wrapping bytes change.
Three adjacent cryptographic primitives shape the choice landscape. **ECDSA** (Elliptic Curve Digital Signature Algorithm) gets the same security level at a fraction of the key size — 256-bit ECDSA ≈ 3072-bit RSA — but is fragile if the nonce is reused, which has bitten several deployments. **Ed25519** (Bernstein's twisted Edwards curve, RFC 8032) is the modern best-of-both — small keys, fast operations, no nonce-reuse landmines, but newer enough that some legacy platforms do not accept it. **Post-quantum** algorithms (CRYSTALS-Kyber for KEM, CRYSTALS-Dilithium for signatures) are entering production in 2024–2026 because RSA and EC algorithms will be broken by a sufficiently large quantum computer. RSA stays dominant because the install base is enormous, but newer systems should default to Ed25519 today and plan PQ migration for the next decade.
