RSA Encryption, Decryption, Signatures and Key Generation

Features

• Five operations: generate a key pair, encrypt, decrypt, sign, verify
• Generate a 1024 / 2048 / 3072 / 4096-bit RSA key pair locally, emitted as PKCS#8 private and SPKI public PEM
• All four PEM headers, PKCS#1 included (the ASN.1 shell is added for you)
• Keys with line breaks, indentation and surrounding whitespace work as pasted
• Ciphertext and signatures as Base64 or hexadecimal
• OAEP-SHA256 for encryption, RSASSA-PKCS1-v1_5 for signatures (the most compatible choice)
• Supplying the wrong kind of key is named explicitly, rather than surfacing as a padding error

How to use

1. Choose the operation: generate a key pair, encrypt, decrypt, sign or verify
2. When encrypting or signing, paste the PEM key into the key field; generation needs no key
3. For verification, also fill in the signature field
4. Paste the content and press Ctrl/⌘ + Enter, or click Run; 3072 / 4096-bit keys take a few seconds

FAQ

Why is PKCS#1 v1.5 encryption not available?

Because the browser Web Crypto API implements only OAEP. That is deliberate: v1.5 encryption suffers from the Bleichenbacher padding-oracle attack — by distinguishing "bad padding" from "padding fine but content wrong", an attacker recovers the plaintext step by step, and variants have kept appearing since 1998. The specification therefore excludes it from encryption while keeping it for signatures, where no padding oracle arises. So this tool cannot do `RSA/ECB/PKCS1Padding`, a very common spelling in older systems — that needs a server or a dedicated library.

How much data can RSA encrypt?

Very little, and it scales with the key: RSA-OAEP with SHA-256 caps a 2048-bit key at 190 bytes (256 minus two 32-byte hashes minus 2), and a 4096-bit key at 446 bytes. Exceeding that fails. This is not an implementation limit but a consequence of RSA's mathematical structure. For longer content the standard approach is hybrid encryption: generate a random AES key to encrypt the payload, then encrypt only that AES key with RSA — and an AES key is 16 or 32 bytes, comfortably inside the limit.

What is the difference between signing and encrypting?

Encryption answers "nobody else can read it" (encrypt with the recipient's public key; only they can decrypt with the private one). Signing answers "this really came from them, unmodified" (sign with your own private key; anyone verifies with your public one). They run in opposite directions: encryption goes public key in, private key out; signing goes private key in, public key out. Real systems often use both — sending a contract might encrypt with the recipient's public key for confidentiality while signing with your own private key for provenance. The two modes here map exactly onto those jobs; just be careful not to swap the keys.

What does "Generate a key pair" produce, and which size should I pick?

Two standard PEM blocks: a PKCS#8 private key and an SPKI public key, created from the browser's cryptographic random source and existing only in this output. On size, 2048 bits is the recommended choice today — enough security with good compatibility; 1024 bits is no longer considered secure (its factorisation cost is within reach) and belongs only in legacy integrations; 3072 / 4096 resist the future better, at the cost of a few seconds of generation and slower operations afterwards. Generation is pure computation: after you click, give it a moment — 3072 / 4096 bits is not a freeze, it is arithmetic.