RSA Encrypt & Decrypt

Free online RSA Encrypt & Decrypt tool. 100% local processing — your data never leaves your device.

National Standards
Other
Output

Result will be displayed here...

Input → Encrypt

Usage Guide

About RSA

RSA (Rivest–Shamir–Adleman) is the most widely used asymmetric encryption algorithm, invented in 1977. It uses a mathematically linked key pair: a public key for encryption and a private key for decryption. Security is based on the computational difficulty of factoring large integers. RSA is the foundation of modern secure communications — SSL/TLS certificates, HTTPS, SSH, PGP, and digital signatures all rely on RSA or its variants.

Asymmetric Encryption: Unlike symmetric algorithms (e.g., AES), RSA uses different keys for encryption and decryption. You can freely share the public key — only the holder of the private key can decrypt messages encrypted with it. This property makes secure key exchange over untrusted channels possible.

Usage Steps

This tool supports RSA key pair generation, encryption, and decryption:

•
1. Select Key SizeChoose key size (2048 recommended; 4096 for high security). Larger keys are more secure but slower.
•
2. Generate Key PairClick 'Generate Key Pair' to create a public/private key pair. Both keys are exported in PEM format.
•
3. Save KeysCopy and securely save both keys. The private key must be kept secret — loss means permanent inability to decrypt.
•
4. EncryptPaste the public key, enter the plaintext message, click 'Encrypt'. The output is a Base64-encoded ciphertext.
•
5. DecryptPaste the private key, paste the Base64 ciphertext into the input field, click 'Decrypt' to recover the plaintext.
Privacy Protection: All key generation and cryptographic operations run entirely in your browser. No keys or plaintext are ever sent to a server.

Padding Schemes

RSA requires a padding scheme to be secure. This tool supports two options:

•
OAEP (Recommended)Optimal Asymmetric Encryption Padding with SHA-256. The modern standard — probabilistic, semantically secure, and resistant to chosen-ciphertext attacks. Use OAEP for all new projects.
•
PKCS1v15 (Legacy)PKCS #1 v1.5 padding. Widely supported in older systems but vulnerable to the Bleichenbacher adaptive chosen-ciphertext attack. Use only for compatibility with legacy systems.
Security Warning: Always prefer OAEP padding for new implementations. PKCS1v15 is considered legacy and is vulnerable to the Bleichenbacher attack when not carefully implemented. If interoperating with old systems that only support PKCS1v15, ensure the implementation is protected at the transport layer (e.g., TLS).

Key Size Guide

Choosing the right RSA key size is a balance between security and performance:

•
1024-bit (Weak)No longer considered secure. Breakable with modern computing resources. Do not use for any new system.
•
2048-bit (Minimum)The current industry minimum recommended by NIST and major CAs. Sufficient for most applications through ~2030.
•
3072-bit (Strong)Recommended for systems requiring security beyond 2030. Matches the security level of AES-128.
•
4096-bit (High Security)Matches AES-192 security level. Suitable for long-lived keys (e.g., root CA certificates) but noticeably slower.
Practical Recommendation: Use 2048-bit for everyday use and short-term keys. Use 4096-bit for root certificate authorities or keys intended to remain valid for many years. Note that RSA key size does not affect ciphertext correctness — only the security margin and performance.

FAQ

Q: Why can't RSA encrypt large files directly?

A: RSA can only encrypt data smaller than its key size minus padding overhead. For a 2048-bit (256-byte) key with OAEP-SHA256, the maximum plaintext is only 190 bytes. For large data, the standard approach is hybrid encryption: generate a random AES key, encrypt the data with AES (which handles arbitrary sizes), then encrypt only the AES key with RSA. The recipient decrypts the AES key with their RSA private key, then decrypts the data. This is exactly how TLS and PGP work.

Q: What is the difference between RSA encryption and RSA digital signatures?

A: RSA Encryption: The sender encrypts with the recipient's public key; only the recipient's private key can decrypt. Guarantees confidentiality. RSA Digital Signature: The signer signs with their own private key; anyone with the public key can verify. Guarantees authenticity and non-repudiation. The two operations use the same key pair but in opposite roles. This tool focuses on encryption/decryption. For digital signatures, use RSA-PSS (modern) or PKCS1v15 signing in a dedicated signing library.

Q: What format are the keys exported in?

A: This tool exports keys in standard PEM format:
Private key: PKCS#8 (-----BEGIN PRIVATE KEY-----) — the modern standard that supports multiple algorithms.
Public key: SPKI (-----BEGIN PUBLIC KEY-----) — Subject Public Key Info, widely supported across libraries and languages.
These formats are directly importable by OpenSSL, Node.js crypto, Python cryptography, Java, and most other platforms without conversion.

Q: Is it safe to share the public key publicly?

A: Yes — that is the entire point of asymmetric cryptography. The public key is designed to be freely distributed. Anyone can use it to encrypt data, but only the holder of the corresponding private key can decrypt it. However, keep these points in mind: 1) Never share the private key — it is the secret half of the pair. 2) Verify public key authenticity through a trusted channel or certificate authority to prevent man-in-the-middle substitution. 3) Rotate key pairs periodically for long-lived applications.

Q: When should I use RSA vs AES?

A: RSA is for key exchange and small secrets: it lets two parties establish a shared secret without a pre-shared key, but is slow and limited in plaintext size. AES is for bulk data encryption: fast, handles any size, but requires a pre-shared key. In practice, use them together — RSA to securely transmit an AES key, AES to encrypt the actual data. This hybrid pattern is the backbone of HTTPS, S/MIME, and PGP.

Q: What is the Bleichenbacher attack and why does it matter?

A: The Bleichenbacher attack (1998) is an adaptive chosen-ciphertext attack against PKCS1v15 padding. An attacker who can submit many ciphertexts and observe whether they decrypt with valid padding can eventually recover the plaintext — even without the private key. Many real-world TLS implementations have been vulnerable to variants of this attack (ROBOT attack, 2017). OAEP padding was specifically designed to be provably secure against this class of attack. Always use OAEP for new implementations.

Use Cases

Recommended: Hybrid Encryption with AES

The most common and recommended way to use RSA for real data. Generate a random AES-256-GCM key, encrypt the payload with AES, then encrypt the AES key with the recipient's RSA public key. Transmit both the AES-encrypted payload and the RSA-encrypted AES key. The recipient decrypts the AES key with their RSA private key, then decrypts the payload. This is the pattern used by TLS, PGP, and S/MIME — it combines RSA's key-exchange capability with AES's speed and ability to handle arbitrary data sizes.

Recommended Configuration:
  • ✅ RSA-OAEP (SHA-256) to encrypt the AES key
  • ✅ AES-256-GCM to encrypt the data
  • ✅ 2048-bit RSA minimum; 4096-bit for long-lived keys
  • ❌ Don't encrypt large data directly with RSA
Recommended: Secure Secret Transmission

RSA is well-suited for transmitting small secrets — passwords, tokens, symmetric keys, or configuration values — over untrusted channels. The sender encrypts the secret with the recipient's public key; only the recipient can decrypt. This avoids the need to pre-share a symmetric key. Use OAEP padding and at least a 2048-bit key. Verify the authenticity of the public key before use to prevent man-in-the-middle attacks.

Recommended Configuration:
  • ✅ OAEP-SHA256 padding (recommended)
  • ✅ 2048-bit or 4096-bit key size
  • ✅ Verify public key authenticity (certificate or fingerprint)
  • 💡 Keep secrets under 190 bytes for 2048-bit OAEP-SHA256
Recommended: SSL/TLS Key Exchange (Informational)

TLS 1.2 and earlier used RSA for key exchange: the client encrypted a pre-master secret with the server's RSA public key (from the certificate), and only the server could decrypt it. TLS 1.3 replaced RSA key exchange with Elliptic Curve Diffie-Hellman (ECDHE) for forward secrecy, but RSA certificates are still used for server authentication. Understanding this context explains why RSA key size matters for long-lived certificates.

Recommended Configuration:
  • ✅ 2048-bit minimum for TLS certificates
  • ✅ 4096-bit for root CA certificates
  • ✅ TLS 1.3 preferred (uses ECDHE, not RSA key exchange)
  • 💡 RSA in TLS 1.3 is used for authentication only, not key exchange
Recommended: Digital Signatures (Key Concept)

RSA private keys can sign data, and the corresponding public key verifies the signature. This proves the message came from the private key holder and has not been tampered with. Signature use cases include code signing, document signing, email signing (S/MIME), and JWT (RS256). Use RSA-PSS for new implementations (probabilistic, provably secure); PKCS1v15 signing is legacy but still widely supported. This tool focuses on encryption/decryption — for signing, use a dedicated library.

Recommended Configuration:
  • ✅ RSA-PSS (modern, recommended for signatures)
  • ✅ PKCS1v15 signing (legacy, widely compatible)
  • ✅ Hash the message first (SHA-256 or stronger)
  • 💡 Signatures use private key to sign, public key to verify (opposite of encryption)
Not Recommended: Large File Encryption

RSA cannot directly encrypt data larger than the key size minus padding overhead (≈190 bytes for 2048-bit OAEP-SHA256). Attempting to encrypt large files directly with RSA is both incorrect and insecure. Always use AES for bulk data and RSA only to protect the AES key (hybrid encryption). Additionally, RSA is orders of magnitude slower than AES — even if you could split large data into RSA-sized chunks, the performance would be unacceptable.

Recommended Configuration:
  • ❌ Don't encrypt files or large payloads directly with RSA
  • ✅ Use AES-256-GCM for the data
  • ✅ Use RSA-OAEP to encrypt the AES key only
  • 💡 This hybrid pattern is used by every major secure protocol
Not Recommended: Symmetric-Style Data Encryption

RSA should not be used as a drop-in replacement for symmetric encryption. It is significantly slower (100–1000x), has a strict plaintext size limit, and the ciphertext is the same size as the key (2048 bits = 256 bytes output per block). Using RSA to encrypt repeated, high-volume data is impractical and may expose patterns. For any bulk encryption, always choose AES. RSA's role is key establishment and small-secret transmission, not bulk data encryption.

Recommended Configuration:
  • ❌ Don't use RSA for high-frequency or high-volume encryption
  • ✅ AES-256-GCM for fast, authenticated bulk encryption
  • ✅ Use RSA only for key exchange or small secrets
  • 💡 Combine RSA + AES for the best of both worlds

Best Practice Recommendations

  • Always use OAEP-SHA256 padding for new RSA encryption implementations. PKCS1v15 is legacy and vulnerable to Bleichenbacher-style attacks.
  • Use 2048-bit keys as the minimum; prefer 4096-bit for certificates or keys intended to remain valid beyond 2030.
  • RSA cannot encrypt data larger than ~190 bytes (2048-bit, OAEP-SHA256). For large data, use hybrid encryption: AES for the data, RSA for the AES key.
  • Keep the private key secret and store it securely. Compromising the private key exposes all messages ever encrypted with the corresponding public key.
  • For digital signatures, prefer RSA-PSS over PKCS1v15 signing. Verify the public key's authenticity through a trusted certificate or fingerprint.

Discussion & Feedback

0 comments
Me