Generate an RSA key pair in Linux by opening a browser-based RSA-OAEP generator that uses the platform Web Cryptography implementation, choosing 2048 or 3072 bits, and exporting the result as SPKI public PEM and PKCS#8 private PEM — no openssl or ssh-keygen required. The browser tab calls WebCrypto generateKey, which creates two large primes and a public exponent of 65537, then Base64-wraps each DER envelope at 64 columns. No key bytes leave your machine. The public PEM begins with BEGIN PUBLIC KEY and can be handed to any system that needs to encrypt for the holder; the private PEM begins with BEGIN PRIVATE KEY and must be imported directly into a secret manager. Because RSA only encrypts short payloads, the typical production pattern is to wrap a random symmetric key with RSA-OAEP and protect the actual data with an authenticated symmetric cipher. The whole flow takes a few moments at 2048 bits and noticeably longer at 3072, and a round-trip encryption test should pass before you trust the key in a real protocol.
When the Browser Method Fits on a Linux Box
Linux administrators usually reach for openssl genrsa or ssh-keygen the moment they hear "RSA key pair." Those commands are excellent for SSH authentication keys and for OpenSSL-style private keys used by Apache, nginx, or a private CA, and they are part of the standard workflow for most server roles. They also assume you have a terminal, the right packages installed, and write access to a filesystem path where the private key can land. There is a different situation where the browser route is more convenient: the receiving application expects a clean SPKI public envelope and a PKCS#8 private envelope, the deliverable is a short PEM string that gets pasted into a config field, or the keys must be generated on a machine that does not have OpenSSL at all (a locked-down workstation, a recovery environment, or a kiosk).
The RSA Key Generator in Lizely fits that second case. It runs entirely inside the browser tab, asks the platform Web Cryptography implementation for a fresh RSA-OAEP key, exports the public half as SPKI DER, exports the private half as PKCS#8 DER, and Base64-wraps each at 64 columns so the result is portable text. Generation happens on the client, no bytes are sent to a server, and the output is ready to paste into a config file or hand to a colleague through a secure channel.
Behind the PEM: RSA-OAEP, SPKI, and PKCS#8
The acronyms on the page matter because the consumer application has to agree on them or it will reject the key on import. RSA-OAEP is the Optimal Asymmetric Encryption Padding defined in RFC 8017, and it is the safer of the two common RSA encryption paddings; the older PKCS#1 v1.5 padding is still seen in legacy systems and is not what this generator produces. SHA-256 is the hash function used inside the OAEP mask-generation step. Exponent 65537 is the standard public exponent — every serious RSA implementation uses it, and the browser tool hard-codes it so a custom exponent cannot accidentally weaken the key.
SPKI stands for Subject Public Key Info; it is the ASN.1 envelope defined by RFC 7468 that wraps a public key together with the algorithm identifier (here, rsaEncryption). PKCS#8 is the matching envelope for private keys. The PEM files you copy out of the tool literally begin with BEGIN PUBLIC KEY (SPKI) and BEGIN PRIVATE KEY (PKCS#8). If the application expects BEGIN RSA PUBLIC KEY or a passphrase-encrypted envelope, the format conversion is a separate task and a topic on its own.
Create the RSA Key Pair in Three Actions
- Confirm the application requirements. Verify that the consumer accepts RSA-OAEP with SHA-256, exponent 65537, SPKI for the public half, and PKCS#8 for the private half. If the spec says SHA-1, PKCS#1 v1.5, or a password-encrypted private PEM, this tool will not produce a compatible output.
- Pick 2048 or 3072 bits and generate. Open the RSA Key Generator page, choose the modulus size, and click generate. The first run takes a few moments; a 3072-bit key takes noticeably longer because the underlying prime generation is more expensive. The page shows both PEM outputs when generation finishes.
- Distribute the keys and run a round-trip test. Copy the public PEM to any system that needs to encrypt for the holder. Import the private PEM directly into protected storage — a secret manager, an HSM-backed keystore, or an encrypted volume — without pasting it into chat, email, source control, or browser sync. Then perform an end-to-end encryption test with the exact application protocol before treating the key as live.
2048 vs 3072 Bits: What Changes in Practice
The two supported modulus sizes give different trade-offs between compatibility, security margin, and browser cost. The choice has no effect on the output format — both produce SPKI public PEM and PKCS#8 private PEM with the same headers — but it changes how long generation takes and how much headroom the key has against future factoring improvements.
| Property | 2048-bit RSA | 3072-bit RSA |
|---|---|---|
| Generation time in the browser | A few moments; runs on commodity hardware without blocking the tab. | Noticeably longer than 2048; the page stays responsive but you should plan for a short wait. |
| Security margin against factoring | Broadly interoperable; widely accepted for general use today. | Larger modulus provides a stronger margin against future factoring improvements. |
| Compatibility | Broadly interoperable across modern systems. | |
| Operational cost | Encryption and decryption are faster at this size. | Encryption and decryption operations are slower than at 2048 bits. |
| Recommended use | Default choice for most application integrations where RSA is required. | Pick when the spec mandates it or when the extra margin is worth the slower generation. |
If you are unsure, stay with 2048 — it is the broadly interoperable default and is what the vast majority of consumer applications will accept. Choose 3072 only when the application spec explicitly asks for it, or when a longer retention period and stronger factoring margin outweigh the slower generation time.
Move the Private PEM Into Protected Storage
The PKCS#8 PEM exported by the tool is unencrypted. Anyone who obtains that block can decrypt any ciphertext produced for the matching public key, so the PEM itself is the secret. The correct pattern is to copy the private block once, import it into the destination secret manager or HSM-backed keystore, then close the tab and clear the clipboard history. Do not paste the private PEM into source control, ticketing systems, chat windows, analytics dashboards, browser sync, or ordinary notes. Do not screenshot it. Do not leave it in a downloads folder on a shared host.
The browser tab keeps the private material only in component memory until you navigate away or generate a fresh pair, but anything outside the browser — extensions, clipboard managers, malware, screenshots, and cloud-synced clipboard history — is outside that boundary. Generate on a trusted, fully patched device, and rotate the key immediately if there is any chance the private PEM was exposed.
Run an End-to-End Encryption Test Before You Trust It
A PEM that imports without error is not proof that the parameters match what the consumer expects. RSA-OAEP declares SHA-256 here, but another system may default to SHA-1 or use a different label and mask-generation function. The verification path is to encrypt a known UTF-8 message with the generated public key on the consumer side, send the ciphertext to the private-key holder, and decrypt it back to the exact original bytes. If the round trip succeeds, the parameters match and the key is usable. If decryption fails with a padding or OAEP error, the hash, label, or padding mode does not agree — investigate the consumer's configuration before treating the key as live.
Limits and Adjacent Formats This Tool Does Not Produce
The RSA Key Generator is deliberately narrow. It does not create X.509 certificates, certificate signing requests (CSRs), SSH keys, JSON Web Keys, or RSA-PSS signatures. The private output is not wrapped in a password-based encryption envelope; if the consumer expects that, you must convert the PEM outside this tool while protecting the plaintext. The tool also does not support custom public exponents, raw RSA without OAEP padding, or the older SHA-1 hash inside OAEP, because fixed safer defaults reduce accidental misuse.
RSA-OAEP only encrypts payloads up to a small size limit — roughly 190 bytes for 2048-bit keys after padding. Production systems therefore wrap a fresh symmetric key with RSA-OAEP and protect the actual data with an authenticated symmetric cipher; do not try to split a large file into raw RSA blocks. For production identity, TLS, or signing workloads, prefer the key-generation workflow provided by the owning platform or hardware security module rather than a browser tab.