Can I paste this PEM directly into GitHub as an SSH key?

No. GitHub's SSH key form expects a single-line OpenSSH public key starting with ssh-rsa, ssh-ed25519, or similar. The RSA Key Generator exports SPKI PEM, which GitHub will reject. Use ssh-keygen to create OpenSSH keys for repository authentication, or convert the PEM externally if you need both formats.

Does the RSA Key Generator send my keys to a server?

No. Key generation, export, and import run entirely in your browser through Web Crypto. No key bytes are transmitted. Browser extensions, clipboard managers, and malware remain outside this guarantee, so use a trusted, patched device.

Why is the private PEM not password-protected?

Web Crypto exports PKCS#8 bytes without an encryption envelope here. The private PEM must be moved immediately into a keystore, secret manager, or encrypted storage that provides its own access control. Leaving it as plain text on disk is unsafe.

Can I generate an X.509 certificate, CSR, or signature with this tool?

No. The generator produces RSA-OAEP encryption keys only. It does not create X.509 certificates, CSRs, signatures, SSH keys, or JSON Web Keys. For TLS server identity, use the platform's certificate workflow or a hardware security module.

Should I choose 2048 or 3072 bits?

2048 bits is broadly interoperable and faster to generate. 3072 bits provides a larger security margin but takes longer and produces larger ciphertext. Pick 2048 for general GitHub-adjacent encryption and 3072 when you need the extra margin and the consumer supports it.

How do I convert this PEM to OpenSSH format?

Use ssh-keygen with the -i -f options, or an external library like OpenSSL to convert the SPKI or PKCS#8 PEM. The conversion is possible but should be done on a trusted machine because the private key material is exposed during the process.

Generate an RSA Key for GitHub Without OpenSSL

The RSA Key Generator produces a fresh RSA-OAEP key pair with a 2048- or 3072-bit modulus, exponent 65537, and SHA-256 padding, exported as SubjectPublicKeyInfo and PKCS#8 PEM blocks entirely in your browser. For GitHub-related work, the practical question is which RSA format your consumer expects. GitHub's primary authentication path—pushing and pulling over SSH—uses OpenSSH-format keys generated by ssh-keygen, not raw PEM. The RSA Key Generator instead targets RSA-OAEP encryption workflows where a public key is distributed to a remote system and a PKCS#8 private key is imported into a protected keystore. Examples include encrypting a symmetric data key for a GitHub Actions secret, protecting an artifact sent to a release workflow, or feeding key material into a CI pipeline that expects SPKI public input. All key generation, export, and import handling happens locally through Web Crypto; the bytes never leave the tab, and the page makes no network request with the generated material. The remainder of this article walks through confirming the consumer's requirements, generating the pair, reading the PEM output, and storing the private key safely.

generate rsa key for github — Generate an RSA Key for GitHub Without OpenSSL

GitHub RSA Keys: SSH Authentication vs RSA-OAEP

GitHub accepts two main credential types for repository access: SSH keys in OpenSSH format (typically Ed25519 or RSA) and personal access tokens over HTTPS. The OpenSSH format is a single line beginning with ssh-rsa or ssh-ed25519, produced by tools like ssh-keygen or PuTTYgen. The RSA Key Generator does not produce OpenSSH keys, and pasting an SPKI PEM block into GitHub's "Add SSH key" form will be rejected by the web UI.

RSA-OAEP PEM pairs generated here fit a different role. They are useful when an application, script, or GitHub Actions workflow needs to encrypt data to a holder's public key, or when a third-party service expects SPKI or PKCS#8 PEM input. Before generating, confirm the exact algorithm, padding, hash, and envelope expected by the recipient. If the consumer documents RSA-OAEP with SHA-256 and one of these two PEM types, the generator matches. For repository SSH authentication, follow a dedicated workflow such as the PEM vs OpenSSH comparison or use ssh-keygen directly.

The distinction matters because GitHub's SSH form performs format-specific parsing. OpenSSH keys carry a key-type prefix, a base64 blob, and a comment. SPKI PEM carries ASN.1 structure wrapped in -----BEGIN PUBLIC KEY----- markers as defined in RFC 7468. The two encodings are not interchangeable, and a successful PEM import into a Web Crypto context does not imply that the same block will be accepted as an SSH credential.

Generate an RSA Key Pair in Your Browser

Confirm the consumer expects RSA-OAEP with SHA-256, exponent 65537, and either SPKI public PEM or PKCS#8 private PEM. The pair will not interoperate with a system that defaults to SHA-1, PKCS#1 v1.5 padding, or a custom exponent.
Open the RSA Key Generator and choose 2048 or 3072 bits. The 2048-bit modulus is broadly interoperable and faster to generate; 3072 bits provides a larger margin at the cost of noticeably longer generation and slower operations.
Click Generate and wait for the Web Crypto operation to finish. Generation is asynchronous, and a job identity prevents an older request from overwriting newer settings.
Copy the -----BEGIN PUBLIC KEY----- block to distribute to the encrypting system, and import the -----BEGIN PRIVATE KEY----- block directly into a protected keystore or secret manager. Do not paste the private PEM into source control, chat, or notes.
Run an end-to-end encryption test with the consumer's exact protocol before relying on the pair. A successful import into Web Crypto is necessary but not sufficient; verify that the consumer reports the selected modulus length and that an encrypted round trip recovers the original plaintext byte-for-byte.

Understanding the SPKI and PKCS#8 PEM Output

After generation, the tool displays two PEM blocks. The public key uses the SubjectPublicKeyInfo structure defined in RFC 7468, beginning with -----BEGIN PUBLIC KEY----- and containing the algorithm identifier plus the modulus and public exponent. Any system that needs to encrypt for the holder can read this block. The private key uses the unencrypted PKCS#8 envelope, beginning with -----BEGIN PRIVATE KEY-----, and contains the full private exponent, primes, and CRT parameters needed to decrypt. RFC 8017 specifies the underlying RSA primitives.

Field	Public Key (SPKI)	Private Key (PKCS#8)
PEM header	-----BEGIN PUBLIC KEY-----	-----BEGIN PRIVATE KEY-----
ASN.1 structure	SubjectPublicKeyInfo	PKCS#8 (unencrypted)
Contains	Modulus, public exponent	Modulus, private exponent, primes, CRT
Distribute freely?	Yes	No
Suitable storage	Plain text, repository, documentation	Hardware keystore, secret manager, encrypted vault
Encoding	Base64-wrapped DER at 64 columns	Base64-wrapped DER at 64 columns
Decrypts ciphertext?	No	Yes

The public exponent is fixed at 65537 (0x010001), the F4 value that nearly all RSA implementations expect. The modulus length is either 2048 or 3072 bits, selected by the user. There is no way to choose a different exponent or to embed a passphrase around the private output. Because Web Crypto exports PKCS#8 without an encryption envelope, the private PEM must be moved directly into a keystore or secret manager that provides its own protection.

Secure Storage for the Private Key

The private PEM is the only piece that can decrypt ciphertext intended for the holder. Anyone who obtains it can recover the matching plaintext, so copying it transfers full responsibility for its protection. The generator does not password-encrypt the output, and the contract explicitly states that the private output is not password-protected. Treat it as a high-value secret from the moment it appears on screen.

Suitable destinations include a hardware security module, an OS keystore such as the Windows Certificate Store or macOS Keychain, a cloud secret manager (GitHub Actions encrypted secrets, AWS Secrets Manager, HashiCorp Vault), or an encrypted password manager that supports file attachments. Unsuitable destinations include source control, ticket trackers, chat logs, browser sync, analytics dashboards, or ordinary notes. After importing the private PEM into its destination, close the tab, clear the clipboard history, and remove any local copies.

If the private key is exposed at any point, rotate immediately by generating a fresh pair and re-encrypting any data intended for the old public key. Treat the old private key as permanently compromised; there is no way to retroactively re-protect data already encrypted with its public counterpart. Generating twice with identical settings must produce different keys because secure generation must be random; do not rely on any reproducibility property.

When RSA-OAEP Keys Fit a GitHub Workflow

RSA-OAEP is an asymmetric encryption scheme, not a signing or authentication scheme. The practical GitHub-adjacent use cases are: wrapping a symmetric data key before storing it in a GitHub Actions secret, so that only a holder of the private key can unwrap it; encrypting a release artifact or backup that a downstream CI workflow will decrypt; providing SPKI input to a third-party API or library that expects standard PEM; and bootstrapping a service that exchanges RSA-OAEP ciphertext before switching to a session key. Each of these requires the consumer to document RSA-OAEP with SHA-256 and either SPKI or PKCS#8 PEM.

RSA-OAEP encrypts only limited-size messages. The maximum plaintext length is determined by the formula: (modulus size in bytes) − 2 × (hash size in bytes) − 2. For a 2048-bit modulus (256 bytes) with SHA-256 (32 bytes), that gives 256 − 64 − 2 = 190 bytes. For a 3072-bit modulus (384 bytes), it gives 384 − 64 − 2 = 318 bytes. Applications normally encrypt a random AES or ChaCha20 key with RSA-OAEP and protect the actual payload with an authenticated symmetric cipher. Do not split a large file into raw RSA blocks; the generator does not invent a hybrid format and cannot help with bulk file encryption.

A successful import into Web Crypto is necessary but not sufficient. Confirm that the consumer reports the selected modulus length, that the algorithm name on both sides reads RSA-OAEP, and that the hash and label parameters match. Then perform an end-to-end round trip: encrypt a known UTF-8 message with the public key and assert exact recovery with the private key, using the same protocol the production application will use. If recovery fails, regenerate and re-check the consumer's expected parameters rather than assuming a corrupt key. The generation step locks eight external parameter invariants and tests both PEM envelopes by importing them back into Web Crypto, encrypting a known UTF-8 message with the public key, and asserting exact recovery with the private key.

For a deeper look, see XOR Encryption Online Cheat Sheet: Formats and Keys.