RSA Asymmetric Cryptography
Generate RSA key pairs, encrypt/decrypt with RSA-OAEP, sign and verify with RSASSA-PKCS1-v1_5. All operations in-browser via Web Crypto API.
1. Key Pair
2. Encryption / Decryption (RSA-OAEP with SHA-256)
3. Sign / Verify (RSASSA-PKCS1-v1_5 with SHA-256)
Uses Web Crypto API with RSA-OAEP (SHA-256) for encryption and RSASSA-PKCS1-v1_5 (SHA-256) for signatures. Keys are generated in-browser and never leave your device. PEM export uses PKCS#8 (private) and SPKI (public) format.
How to Use
Encryption: Generate a key pair, enter your message, click "Encrypt with Public Key". Share the Base64 ciphertext and the private key holder can decrypt it.
Decryption: Paste the Base64 ciphertext, ensure the corresponding private key is loaded, click "Decrypt with Private Key".
Signing: Enter a message, click "Sign with Private Key" to produce a Base64 signature. Anyone with the public key can verify the signature was produced by the private key holder.
Key export: Use the Copy buttons to export public/private keys in PEM format for use in other systems (OpenSSL, Java, Python).
Example Use Cases
- Key exchange — Encrypt a symmetric key with the recipient's RSA public key
- Digital signatures — Sign documents to prove authenticity and integrity
- Certificate testing — Generate test key pairs for TLS/mTLS development
- JWT signing — Test RS256 JWT signatures with generated keys
Understanding RSA Cryptography
RSA, invented by Rivest, Shamir, and Adleman in 1977, remains the most widely deployed public-key cryptosystem in the world. Its security rests on the practical difficulty of factoring the product of two large prime numbers. Every RSA key pair consists of a public key (n, e) and a private key (n, d), where n is the modulus (the product of two primes p and q), e is the public exponent (typically 65537), and d is the private exponent derived from e and the totient φ(n) = (p-1)(q-1).
Key Size and Security Margin
The modulus length directly determines security strength. A 2048-bit RSA key provides approximately 112 bits of security, roughly comparable to a 2048-bit Diffie-Hellman group or a 224-bit elliptic curve. NIST SP 800-57 recommends 2048-bit for use through 2030 and 3072-bit for protection beyond that. 4096-bit keys offer a comfortable margin but double signing and decryption time compared to 2048-bit. For most production TLS certificates and JWT signing, 2048-bit is the sweet spot — it balances security with performance on constrained devices. Avoid 1024-bit keys entirely; they have been broken in practice and are forbidden by modern standards like FIPS 186-5 and CA/Browser Forum Baseline Requirements.
OAEP vs PKCS#1 v1.5 Padding
Raw RSA without padding is deterministic and catastrophically insecure — the same plaintext always produces the same ciphertext, enabling dictionary attacks. Two padding schemes fix this. PKCS#1 v1.5 (RFC 8017 Section 7.2) adds random padding bytes but has known vulnerabilities to Bleichenbacher's adaptive chosen-ciphertext attack (1998) and its variants. Manger's attack (2001) showed that even OAEP can be vulnerable if the error handling leaks timing information. RSA-OAEP (Optimal Asymmetric Encryption Padding, RFC 8017 Section 7.1) uses a hash-based construction with a label parameter and is the recommended scheme for encryption. This tool uses OAEP with SHA-256 for encryption. For signatures, RSASSA-PKCS1-v1.5 is still widely used and considered secure (signatures are not vulnerable to the same adaptive attacks as encryption), though RSASSA-PSS is the more modern alternative recommended for new systems.
The Public Exponent: Why 65537?
The public exponent e must be coprime to φ(n). Historically, small exponents like 3 or 17 were used for performance, but they introduce vulnerabilities in certain padding scenarios. The value 65537 (0x010001, or F4 in Fermat prime notation) has become the universal standard because it is large enough to avoid small-exponent attacks while still being small enough that me mod n requires only 17 multiplications via square-and-multiply. All modern cryptographic libraries default to 65537, and this tool follows that convention.
Message Size Limits and Hybrid Encryption
RSA can only encrypt data smaller than the modulus. With OAEP padding, the maximum message length is keySize/8 - 2×hashLen - 2 bytes — for a 2048-bit key with SHA-256, that is 190 bytes. This is by design: RSA is meant for encrypting symmetric keys, not bulk data. The standard pattern is hybrid encryption: generate a random AES-256 key, encrypt the data with AES-GCM, then encrypt the AES key with RSA-OAEP. The recipient decrypts the AES key with their RSA private key, then decrypts the data. This combines RSA's key management benefits with AES's speed and unlimited message size.
PEM, DER, and Key Formats
This tool exports keys in PEM format, which is Base64-encoded DER wrapped in header/footer lines. Public keys use SPKI (Subject Public Key Info, RFC 5280) format, recognizable by the -----BEGIN PUBLIC KEY----- header. Private keys use PKCS#8 format (-----BEGIN PRIVATE KEY-----), which wraps the raw RSA private key in an algorithm identifier. Some systems use the older PKCS#1 format (-----BEGIN RSA PRIVATE KEY-----), which omits the algorithm wrapper. You can convert between formats using OpenSSL: openssl rsa -in key.pem -pubout for SPKI, openssl pkcs8 -topk8 -in key.pem for PKCS#8.
Common Pitfalls
Never use the same key for encryption and signing. While the underlying math is identical, the security proofs and padding schemes differ. Mixing them can open subtle side-channel vulnerabilities. Always use fresh padding — reusing the same ciphertext or sending the same message multiple times with PKCS#1 v1.5 reveals the plaintext. Verify error handling — implementations that return different error messages for padding failures can leak information (Bleichenbacher's attack). OAEP mitigates this but only if the implementation is constant-time. The Web Crypto API used by this tool handles all of this correctly internally.