RSA Encryption & Decryption Tool
Online RSA asymmetric encryption with key pair generation, public key encryption, and private key decryption
Key Management
What is RSA Encryption?
RSA (Rivest-Shamir-Adleman) is the world's first widely used asymmetric encryption algorithm, invented in 1977 by three MIT mathematicians: Ron Rivest, Adi Shamir, and Leonard Adleman. Unlike symmetric algorithms like AES, RSA uses a key pair: a public key for encryption and a private key for decryption. The public key can be shared openly while the private key must be kept secret, fundamentally solving the key distribution problem. RSA's security is based on the mathematical difficulty of factoring large integers - multiplying two large primes is easy, but factoring the result back is extremely hard. Keys of 2048 bits or longer are currently recommended, as 1024-bit keys are no longer considered secure. Quantum computing poses a potential threat to RSA, but practical quantum computers don't yet exist. RSA is used in HTTPS/TLS handshakes for key exchange, digital signatures and authentication (SSH, code signing), email encryption (PGP/GPG), and blockchain transaction signing. In practice, RSA typically encrypts symmetric keys (like AES keys), which then encrypt the actual data - this hybrid approach balances security and performance. This tool uses the browser's native Web Crypto API for RSA operations, with all processing done locally.
How to Use
How to use
- Select key size (2048-bit or above recommended)
- Select padding scheme (OAEP recommended for better security)
- Select hash algorithm (SHA-256 recommended)
- Click 'Generate Key Pair' to create public and private keys
- For encryption: paste public key into the public key area, enter plaintext, ciphertext is generated automatically
- For decryption: paste private key into the private key area, enter ciphertext, plaintext is generated automatically
- Copy results or click 'Swap' to exchange input and output
Parameter Guide
- Use RSA-OAEP with SHA-256 or stronger for new encryption tests; PKCS#1 v1.5 should only be used for legacy compatibility.
- RSA can only encrypt small payloads. For larger data, encrypt a random AES key with RSA and use AES for the actual content.
- Keep private keys out of chats, tickets, screenshots, and shared logs. Public keys can be shared, but private keys must remain secret.
Use Cases
Technical Principle
RSA is the 1977 Rivest-Shamir-Adleman public-key cryptosystem. Key generation picks two large random primes p and q, sets the modulus n = p · q, computes Euler's totient φ(n) = (p-1)(q-1), chooses a public exponent e coprime with φ(n) (e = 65537 = 2^16 + 1 is the de-facto default because its low Hamming weight speeds up modular exponentiation), and derives the private exponent d ≡ e^-1 (mod φ(n)) via the extended Euclidean algorithm. Encryption is c = m^e mod n; decryption is m = c^d mod n. Security rests on the conjectured hardness of factoring n into p and q for sufficiently large n. Raw RSA is deterministic and malleable, so every real deployment wraps the message in a padding scheme. RSA-OAEP, defined in RFC 8017 (PKCS#1 v2.2) with a mask generation function MGF1 over SHA-256 (or SHA-1/384/512), gives semantic security: the same plaintext encrypts to a different ciphertext on every call, and the padding integrity check stops chosen-ciphertext attacks. The older PKCS#1 v1.5 padding is still common for backward compatibility but is vulnerable to the Bleichenbacher million-message oracle attack. For signatures, RSASSA-PSS is preferred over PKCS#1 v1.5 sign for the same reasons. Key-size choice is bounded by both performance and the latest factoring records. NIST SP 800-57 mandates ≥ 2048 bits today and ≥ 3072 bits after 2030. Elliptic-curve cryptography matches RSA 3072 at only 256 bits (NIST P-256, Curve25519), which is why most new TLS deployments prefer ECDHE + ECDSA. RSA-OAEP on a 2048-bit key can wrap at most ⌊keysize/8⌋ − 2·hashLen − 2 bytes of plaintext (≈ 190 bytes for SHA-256), so production systems use RSA only to wrap a fresh symmetric session key and let AES-GCM carry the payload — the hybrid pattern behind every TLS handshake. In the browser, the Web Crypto API (window.crypto.subtle) handles key generation, import, encrypt, and decrypt with PEM/DER (SPKI for public, PKCS#8 for private) or JWK as the on-the-wire formats.
- Math: choose primes p, q; n = p·q; φ(n) = (p-1)(q-1); pick e (typically 65537 = 2^16+1); compute d = e^-1 mod φ(n); encrypt c = m^e mod n; decrypt m = c^d mod n.
- Padding: RSA-OAEP per RFC 8017 (PKCS#1 v2.2) with MGF1+SHA-256 for new code; PKCS#1 v1.5 only for legacy interop, subject to Bleichenbacher (CVE-2017-13099 et al).
- Key sizes: NIST SP 800-57 floors at 2048 bits today and 3072 bits from 2030; 1024-bit RSA is considered broken and 4096-bit costs noticeably more CPU.
- Payload limit: RSA-OAEP can wrap at most ⌊k/8⌋ − 2·hashLen − 2 bytes (≈ 190 bytes for 2048-bit + SHA-256); larger data uses RSA to wrap an AES-GCM session key.
- Comparable strength: RSA 3072 ≈ ECC 256 (NIST P-256 or Curve25519) at ~128-bit symmetric security; ECC wins on key size and signing speed, RSA wins on verification.
- Browser API and formats: window.crypto.subtle.generateKey('RSA-OAEP'); export as SPKI PEM (public) and PKCS#8 PEM (private), or JWK; private keys must never leave the local environment in plaintext.
Examples
Basic Encryption
1. Generate 2048-bit key pair
2. Copy the public key
3. Enter plaintext: Hello, RSA!
4. Select OAEP + SHA-256
5. Output: Base64-encoded ciphertext
RFC: RFC 8017 (PKCS#1 v2.2) defines RSAES-OAEP encryption schemeTypical Workflow
Sender:
1. Obtain recipient's public key
2. Encrypt message with public key
3. Send ciphertext
Recipient:
1. Decrypt with private key
2. Read original message
Note: RSA encryption provides confidentiality; for authenticity, combine with RSA signatures (RSASSA-PSS in RFC 8017)Hybrid Encryption (RSA + AES)
RSA is for small data (like session keys)
For large data, use hybrid encryption:
1. Generate random AES-256 key
2. RSA encrypts the AES key (max ~190 bytes with OAEP-SHA256)
3. AES-GCM encrypts the actual data
4. Send RSA-encrypted key + AES ciphertext + IV + auth tag
This combines RSA's key distribution with AES's speed and is the standard pattern in TLS, PGP, and S/MIME.
RFC: RFC 8017 section 7.1 discusses RSAES-OAEP for key encapsulationFAQ
What key size should I generate?
RSA-2048 is the practical minimum today and is what TLS certificates have used for years. RSA-3072 is the conservative current default per NIST SP 800-57. RSA-4096 is overkill for most uses (much slower) but appropriate for long-lived signing keys. RSA-1024 is broken-by-policy and should not be generated for anything new.
Public key vs. private key - which one encrypts and which decrypts?
For confidentiality: encrypt with the public key, decrypt with the private key. Anyone can encrypt a message to you; only the holder of the private key can read it. For signatures it is the opposite: sign with the private key, verify with the public key.
Why does encrypting the same text twice give different ciphertext?
RSA-OAEP (the recommended padding scheme) adds randomness so identical plaintexts produce different ciphertexts. That is by design - it prevents chosen-ciphertext attacks. RSA without padding (textbook RSA) is deterministic and insecure; do not use it.
Why is RSA so much slower than AES?
RSA does big-integer modular exponentiation; AES does fixed-size bit operations on a small block. A 2048-bit RSA encrypt is thousands of times slower than an AES-128 encrypt. In practice you use RSA only to wrap a small AES session key, then encrypt the actual payload with AES.
What is the maximum data I can encrypt with one RSA key?
RSA-OAEP with SHA-256 leaves about (key_size_in_bits / 8 - 66) bytes available per encryption: 190 bytes for a 2048-bit key, 318 bytes for 3072, 446 bytes for 4096. To encrypt anything larger, encrypt an AES key with RSA and the data with AES.
Is the key generation random and local?
Yes. Key generation uses crypto.subtle.generateKey from the Web Crypto API, which seeds from the OS CSPRNG. Keys never leave your browser. Refresh the page to discard a key and generate a fresh one; do not paste a production private key into any web page.
Is RSA quantum-safe?
No. A sufficiently large quantum computer running Shor's algorithm breaks RSA at any practical key size. NIST has standardised post-quantum alternatives (ML-KEM, ML-DSA in 2024). For data that must stay confidential decades from now, plan a migration; for short-lived TLS sessions, RSA is still fine.