RSA Key Pair Generator

RSA, named after Rivest, Shamir, and Adleman who published it in 1977, is one of the most-deployed asymmetric cryptographic algorithms in history. Almost every TLS handshake from 1995 to 2018 used RSA for key exchange; even today, with elliptic-curve alternatives like ECDSA and Ed25519 ascendant, RSA still backs a huge share of CA certificates, code-signing keys, SSH host keys, JWT signatures, and S/MIME email. Its security rests on the difficulty of factoring the product of two large primes — a problem that has stayed hard despite four decades of research, even with advances in number-field-sieve algorithms.

Key sizes — what's safe today, what's safe in 2030

The minimum RSA key size considered cryptographically sound in 2026 is 2048 bits. Below that (1024 and lower) the work factor for an academic factoring attack has dropped to the point where well-funded adversaries can reasonably attempt it. 2048-bit keys remain safe against any publicly-known attack and will likely stay so through the late 2020s; 3072-bit keys are equivalent to 128-bit symmetric security strength per NIST guidance and are the recommended default for new deployments today. 4096-bit keys offer a comfortable margin for long-lived signing keys (CA roots, S/MIME identities held for years) but are overkill for ephemeral TLS keys rotated every 90 days via Let's Encrypt.

PEM, DER, OpenSSH, and JWK — same key, different wrappers

An RSA keypair is mathematically just a pair of large integers (modulus and private exponent). The format wrappers serve different ecosystems. DER is the canonical binary encoding (ASN.1 SEQUENCE of integers). PEM is DER base64-encoded with -----BEGIN/END labels — the format you'll see in /etc/ssl/private/ on every Linux server. OpenSSH format is a different wire format used in ~/.ssh/id_rsa with its own header structure. JWK (JSON Web Key, RFC 7517) is a JSON object with the key components as base64url-encoded fields — used by every JWT library, the JOSE spec family, and OAuth/OIDC /jwks.json endpoints. All four contain the same mathematical material; conversion between them is mechanical.

Why ECDSA and Ed25519 are taking over

RSA's main weakness is verbosity. A 256-bit Ed25519 key has the same security level as a 3072-bit RSA key — twelve times shorter to transmit and several times faster to sign with. TLS 1.3 explicitly prefers elliptic-curve cipher suites; modern SSH installs default to Ed25519 when you run ssh-keygen without arguments; the JOSE spec includes EdDSA alongside RS256. RSA persists because it's universally supported (every embedded device, every legacy system, every CA), well-understood, and "good enough" — but for new keys with no legacy constraints, Ed25519 or ECDSA-P-256 are the better default. We will ship an Ed25519 generator as a separate tool in a future update.

Don't paste production private keys into web tools

A consistent piece of advice from every security review: do not paste production private keys into any browser-based tool, including this one. The reasoning is identical to the TOTP-secret warning — once a private key sits in your tab's JavaScript heap, it is accessible to any malicious browser extension, any XSS bug, and any data-stealing malware on your machine. For test keys, learning, integration verification, or developer experimentation: this tool is fine. For real keys protecting real assets, use a workstation-local tool (ssh-keygen, openssl genrsa), a password manager with key-storage features (1Password, Bitwarden), or a hardware security module (YubiKey, AWS CloudHSM, GCP Cloud HSM, AlibabaCloud KMS).