RSA Key Pair Generator

Know exactly what this RSA generator creates

RSA is an asymmetric cryptosystem: a key pair contains mathematically related public and private components. Public distribution does not reveal the private key under accepted assumptions, while operations performed with one component can be checked or reversed only in the mode defined by the corresponding component and padding scheme.

The button on this page creates a 2048-bit RSASSA-PKCS1-v1_5 signing key pair with SHA-256 through the browser Web Crypto API. Its allowed operations are sign for the private key and verify for the public key. It does not generate an RSA-OAEP encryption key, an SSH key pair, a TLS certificate, or a certificate signing request. That difference is enforced by Web Crypto key usages; PEM text that looks similar does not make keys interchangeable across protocols.

Generation is client-side and uses the browser’s cryptographic random source. The keys are marked extractable so the component can export and display them. That is convenient for format experiments, integration fixtures, and temporary development tests, but undesirable for high-value production private keys. Production signing keys should normally be generated and retained in a controlled keystore, HSM, KMS, or suitably protected offline environment.

Use the output without confusing its containers

Select Generate RSA 2048-bit Key Pair and wait for both panels. The public export is SubjectPublicKeyInfo DER, commonly called SPKI, then standard Base64-wrapped as:

-----BEGIN PUBLIC KEY-----
...
-----END PUBLIC KEY-----

The private export is unencrypted PKCS #8 PrivateKeyInfo DER, represented as:

-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----

PEM is an armor format: header, Base64 body, footer, and line breaks. Base64 is reversible encoding and provides no encryption. Anyone who obtains this private PEM can use its signing capability. The absence of ENCRYPTED in the label is meaningful; copying it into a password-protected note later is not equivalent to an encrypted PKCS #8 structure.

The two Copy controls place complete PEM blocks on the system clipboard. Public keys are intended for distribution after their identity is established. Private keys are not. Clipboard history, synced clipboards, browser extensions, crash reports, and screen sharing can leak a copied private key. Generate another pair if a development key is exposed; do not attempt to “change” a few Base64 characters.

SPKI, PKCS #8, PKCS #1, certificates, and SSH

Key import errors often come from container mismatches rather than bad RSA mathematics. SPKI PUBLIC KEY wraps an algorithm identifier plus RSA public values. A PKCS #1 public key often carries RSA PUBLIC KEY instead. PKCS #8 PRIVATE KEY is an algorithm-neutral wrapper around private-key material, while traditional PKCS #1 private PEM commonly says RSA PRIVATE KEY.

An X.509 certificate says CERTIFICATE and contains a public key plus identity, issuer, validity, extensions, and a CA signature. This generator creates no certificate and makes no identity assertion. A CSR similarly contains a requested identity and proof of private-key possession; it is not produced here.

OpenSSH public-key text begins with a type such as ssh-rsa and uses the SSH wire encoding, not SPKI DER. Although conversion tools may express the same underlying RSA numbers in another container, this page’s public PEM should not be pasted directly into authorized_keys. Moreover, modern SSH deployments often prefer Ed25519; choose the algorithm required by that protocol rather than forcing RSA everywhere.

A signing integration workflow

Create a disposable pair, save each PEM only in an isolated test fixture, and import it into the application under test. Sign a fixed byte message with RSASSA-PKCS1-v1_5 and SHA-256, then verify with the exported SPKI public key. Assert that changing one message byte, one signature byte, or the public key causes verification to fail. Test UTF-8 and raw bytes explicitly so that newline and encoding differences are visible.

Interoperability names vary. OpenSSL and many language APIs call the scheme RSA with PKCS#1 v1.5 signature padding and SHA-256; JSON Web Algorithms calls it RS256. An RS256 JWT signs the encoded header and payload, not arbitrary parsed JSON, and requires additional validation of algorithm, issuer, audience, time claims, and key selection. A successful RSA primitive check alone does not make a JWT verifier secure.

For a command-line fixture matching this page’s format, generate and inspect keys in a trusted local environment:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private.pem
openssl pkey -in private.pem -pubout -out public.pem
openssl pkey -in private.pem -text -noout

Signing and verification must use compatible padding and digest settings. RSA-PSS is a modern probabilistic signature scheme and is not byte-compatible with RSASSA-PKCS1-v1_5. RSA-OAEP is for encryption and cannot verify these signatures. “RSA 2048” alone is an incomplete protocol specification.

Production recommendations

Treat 2048 bits as a compatibility baseline, not a universal lifetime guarantee. Security policy, regulatory requirements, data lifetime, library support, and migration plans determine key size and algorithm. Larger RSA keys increase generation, signature, storage, and handshake costs. Modern designs may prefer Ed25519 for signatures or an appropriate elliptic-curve scheme, but ecosystem requirements can mandate RSA.

Generate production private keys in the boundary where they will live. A cloud KMS may return signatures without revealing private material; an HSM can enforce usage and audit. If file storage is unavoidable, use restrictive permissions, encryption at rest, secure backup, process isolation, and a passphrase or wrapping key managed separately. Avoid environment variables where diagnostics expose them, and never commit PEM files.

Publish public keys with authenticated metadata and stable key IDs. During rotation, introduce the new public key before switching signers, keep the previous verifier only for the required overlap, and reject unknown IDs. Revocation is an operational process, not a property embedded in a bare public key.

Backups require care: no backup means key loss can make signatures or encrypted historical data unusable, but uncontrolled copies multiply compromise risk. Document ownership, recovery, rotation, compromise response, and destruction before relying on a key.

This page does not send key material as part of its generation code, but the broader browser environment remains relevant. Loaded scripts, extensions, developer tools, clipboard services, and a compromised device can inspect extractable keys. For production or certificate-authority work, “generated locally in a browser” is not an adequate threat model by itself.

RSA signatures are not encryption

The historical shorthand “encrypt with the private key” is misleading. Signature schemes encode and hash messages under signature-specific padding; encryption schemes apply encryption-specific padding and confidentiality semantics. Raw textbook RSA is deterministic and malleable and must never be used directly.

For confidential data, use a reviewed hybrid-encryption protocol: an authenticated symmetric cipher protects the payload, while a public-key mechanism protects a random content key. RSA-OAEP can fill that role where RSA is required. It has strict message-size limits and still needs context, authenticity, and key-management design. This page’s keys were generated for signing and verification, not OAEP.

Hashing alone creates a public digest. HMAC authenticates with a shared secret. RSA signatures allow anyone with the public key to verify while only the private-key holder signs. PEM merely carries serialized data. Keeping these layers separate prevents many integration failures.

Mistakes to reject during review

• Calling the displayed public PEM an SSH key or certificate.
• Storing the unencrypted private PEM in source control, logs, tickets, or client-side application assets.
• Accepting a public key from the same untrusted request whose signature it verifies.
• Omitting the padding scheme and hash when documenting “RSA.”
• Using a signing key for decryption or one key pair across unrelated environments and purposes.
• Comparing Base64 signature strings without first handling the protocol’s Base64 or Base64url rules.
• Assuming key generation alone establishes who owns the public key.

FAQ

Can I use these keys for RSA encryption and decryption?

Not through the Web Crypto objects created here. They are RSASSA-PKCS1-v1_5 keys restricted to sign and verify. Generate RSA-OAEP keys for an encryption protocol.

Is the private key PEM password protected?

No. BEGIN PRIVATE KEY here contains unencrypted PKCS #8 data. The Base64 body is directly decodable.

Why will my SSH server not accept the public key?

The output is SPKI PEM, not OpenSSH wire format. Convert with an appropriate tool only if RSA is acceptable for that SSH deployment, or generate an SSH-native key.

Does the public key prove who generated it?

No. Bind it to an identity through a trusted distribution channel, certificate, fingerprint verification, or managed key registry.

Should I generate production keys in this online RSA key pair generator?

Use it for development and format testing. High-value production keys should be non-extractable where possible and generated within the service, HSM, KMS, or offline custody process that will protect them.