The Complete RSA Encryption Guide

RSA (Rivest-Shamir-Adleman) is the world's most popular asymmetric encryption algorithm, proposed in 1977 by three MIT cryptographers — Ron Rivest, Adi Shamir, and Leonard Adleman — after whom the algorithm is named.

RSA is called "asymmetric" because it uses a pair of mathematically related but non-derivable keys:

• Public Key: Can be openly distributed and is used to encrypt data or verify signatures. Anyone can encrypt a message with the public key, but only the holder of the corresponding private key can decrypt it.
• Private Key: Must be kept strictly confidential and is used to decrypt data or create digital signatures. The security of the private key determines the security of the entire RSA system.

RSA has two core applications:

• Data Encryption: The sender encrypts with the receiver's public key; the receiver decrypts with their own private key.
• Digital Signature: The sender signs a message digest with their private key; the receiver verifies the signature with the sender's public key, confirming the authenticity and integrity of the message.

In practical deployment, RSA has become the de facto asymmetric encryption standard worldwide. It is widely used in SSL/TLS certificates (HTTPS website encryption), SSH remote login (key-based authentication), digital signatures and electronic contracts, digital certificates and PKI systems, PGP/GPG email encryption, address generation in blockchain systems like Bitcoin, mobile payment security, and smart cards and hardware security modules — essentially every scenario requiring identity authentication and key exchange. Its security has withstood more than 40 years of public scrutiny by the global cryptography community, and it remains considered secure when using sufficiently long key sizes.

Our online RSA tool preserves the practical value of the algorithm while providing developers with one-stop online encryption/decryption, key generation, signing/verification, and result copying.

RSA security is based on a classic number-theoretic problem: integer factorization. Simply put, multiplying two large primes is easy, but factoring their product back into the original primes is extremely difficult.

The RSA key generation process can be summarized in 6 steps:

• ① Choose two large primes p and q: The bit length of p and q determines the final key size. For example, to generate a 2048-bit RSA key, p and q are typically about 1024 bits each. They must be prime and not too close in value.
• ② Compute the modulus n = p × q: The bit length of n is the RSA key size. n is public and included in both the public and private keys.
• ③ Compute Euler's totient φ(n) = (p-1)(q-1): φ(n) represents the number of positive integers less than n and coprime with n. This value must be kept confidential.
• ④ Choose the public exponent e: Select an integer e such that 1 < e < φ(n) and gcd(e, φ(n)) = 1 (e is coprime with φ(n)). In practice, e is usually 65537 (i.e., 2^16 + 1, the Fermat prime F4), as it provides a good balance between security and computational efficiency.
• ⑤ Compute the private exponent d: d is the modular multiplicative inverse of e modulo φ(n), i.e., (d × e) mod φ(n) = 1. This step is performed using the Extended Euclidean Algorithm.
• ⑥ Output the key pair: The public key is (n, e), and the private key is (n, d). To improve decryption efficiency, real implementations often store additional parameters like p, q, d mod (p-1), and d mod (q-1) to support acceleration via the Chinese Remainder Theorem (CRT).

Encryption uses the public key: encrypt plaintext message m (represented as an integer, 0 ≤ m < n) into ciphertext c = m^e mod n.

Decryption uses the private key: recover plaintext m = c^d mod n. By Euler's theorem and Fermat's little theorem, this recovery process is mathematically exact.

Signing and verification work similarly but in reverse: for signing, the private key operates on a message digest (sign = hash(message)^d mod n); for verification, the public key validates (hash(message) = sign^e mod n).

Once you understand this mathematical structure, you can accurately answer why RSA cannot encrypt data longer than n, why key generation is much slower than encryption/decryption, and why e is commonly set to 65537.

The raw mathematical operation of RSA (direct modular exponentiation on plaintext) has serious security vulnerabilities — it is deterministic, meaning the same plaintext always produces the same ciphertext under the same key, and messages must be smaller than the modulus n. To solve these problems, padding schemes are required in practice.

PKCS#1 v1.5 (Encryption Padding): This is the classic, most compatible padding scheme. The padding structure is 0x00 || 0x02 || PS || 0x00 || M, where PS is at least 8 bytes of random non-zero bytes and M is the plaintext message. Although widely used, it has known padding oracle attack vectors — an attacker can gradually recover plaintext by sending carefully crafted ciphertext and observing decryption failure information. Therefore, PKCS#1 v1.5 is not recommended for new systems.

OAEP (Optimal Asymmetric Encryption Padding): Proposed by Bellare and Rogaway in 1994, it is the standard encryption padding scheme in PKCS#1 v2.0+. Based on a Feistel network structure, combined with a random number (ensuring non-determinism) and two hash functions, OAEP provides provable security (resistance to chosen-plaintext and chosen-ciphertext attacks under the random oracle model). OAEP is the recommended encryption padding scheme today.

PKCS#1 v1.5 (Signature Padding): For signing, the v1.5 padding structure is 0x00 || 0x01 || PS || 0x00 || DigestInfo, where PS is 0xFF padding bytes and DigestInfo contains the hash algorithm identifier and the message digest. While the v1.5 padding for signing is considered more secure than for encryption, PSS is still recommended for new systems.

PSS (Probabilistic Signature Scheme): Also proposed by Bellare and Rogaway, it is the standard signature padding scheme in PKCS#1 v2.1. PSS introduces a random salt so that each signature on the same message produces a different signature value, providing provable security. It is the recommended signature padding scheme today.

Summary: Use OAEP for encryption, PSS for signing; avoid PKCS#1 v1.5 unless legacy compatibility is required.

Additionally, RSA is typically not used directly to encrypt large data. The standard approach is hybrid encryption: generate a random symmetric key (such as an AES key), encrypt this symmetric key with RSA, then encrypt the actual data with the symmetric key. This combines RSA's convenient key distribution capability with the high performance of symmetric encryption.

As the most mature asymmetric encryption algorithm, RSA is nearly ubiquitous in the modern digital world. Here are 7 of the most common real-world use scenarios:

① HTTPS / TLS Website Encryption: When you visit a website starting with https://, RSA is almost certainly involved. The server holds an RSA private key, and the corresponding public key is included in the SSL/TLS certificate. During the handshake phase, the client encrypts a random session key (or pre-master secret) with the server's public key; the server decrypts it with the private key to establish an encrypted channel. Although TLS 1.3 favors ECDHE for key exchange, RSA certificates remain widely used.

② SSH Remote Login: SSH key authentication is one of the most common RSA applications in daily developer work. After generating an RSA key pair, the user adds the public key to the remote server's ~/.ssh/authorized_keys file. During login, the server challenges the client with the public key, and the client responds with the private key, completing password-free authentication.

③ Digital Signatures and Electronic Contracts: In finance, law, government, and other fields, digital signatures are a core infrastructure. A signer signs a document digest with their private key; a verifier verifies the signature's authenticity and non-repudiation with the public key. Certificates issued by CAs (such as VeriSign, DigiCert, Let's Encrypt) are essentially public key certificates signed by the CA's private key.

④ PGP/GPG Email Encryption: Created by Phil Zimmermann in 1991, PGP was one of the first applications to bring RSA to the masses. PGP uses the user's RSA public key to encrypt the session key for email content, and the receiver decrypts with the private key before decrypting the email, ensuring end-to-end email confidentiality.

⑤ Blockchain and Cryptocurrencies: In blockchain systems like Bitcoin and Ethereum, elliptic curve variants of RSA (ECDSA, etc.) are used for address generation and transaction signing. The private key determines the user's control over assets, and the public key (or its hash) is the user's public address on the network.

⑥ Mobile Payments and Financial Security: In payment systems like Apple Pay, Android Pay, and UnionPay cloud flash payment, RSA is used for device authentication, tokenization, and transaction signing. Banks, securities firms, and other financial institutions also widely use RSA for user identity authentication and sensitive transaction signing.

⑦ Software Distribution and Code Signing: Windows Authenticode, macOS Developer ID, Android APK signing, and iOS app signing all use RSA (or its elliptic curve variants) for code signing. Users can verify the authenticity and integrity of software sources by checking signatures, preventing malicious code from disguising as legitimate software.

In these scenarios, RSA typically works with other algorithms (such as AES, SHA-256, ECC) to form a complete security system.

Key size is the primary factor in RSA security. Choosing an appropriate key size requires balancing security, performance, and compatibility.

1024-bit RSA: NOT recommended for any production environment. According to NIST recommendations, 1024-bit RSA has been unsuitable for protecting sensitive information since 2010. With the advancement of computing power and quantum computing research, 1024-bit RSA can be cracked by well-resourced attackers in a reasonable time frame. If your system still uses 1024-bit keys, upgrade immediately.

2048-bit RSA: Currently the minimum recommended standard in industry, and the most common choice. According to NIST SP 800-57 Part 3, 2048-bit RSA is secure at least until 2030. It strikes a good balance between security and performance — key generation, encryption, and decryption speeds are all acceptable, and it's compatible with nearly every system. If you're unsure what to choose, 2048-bit is the default recommendation.

4096-bit RSA: Provides a higher security level, suitable for handling highly sensitive data (such as state secrets, financial transactions, medical records). 4096-bit RSA provides approximately 2^128-level security, much higher than 2048-bit's approximately 2^112 level. The downside is slower performance (key generation is about 5~10 times slower than 2048-bit, and encryption/decryption also has noticeable performance degradation), plus some older systems may not support it.

8192-bit and above: Primarily used for long-term security needs against quantum computing threats, or specific high-security scenarios. Due to extremely slow key generation, 8192-bit RSA is rarely used in ordinary development and testing.

Impact of Quantum Computing: Shor's algorithm can theoretically break RSA in polynomial time, regardless of key size. However, practical general-purpose quantum computers are still a long way off. For data that needs to be protected long-term (e.g., still confidential after decades), consider transitioning to post-quantum cryptography (PQC) or elliptic curve cryptography (ECC).

Practical recommendation: Use 2048-bit for general development and testing; default to 2048-bit or 4096-bit in production systems; use 4096-bit for highly sensitive scenarios and consider future migration to ECC or PQC.

Even with a standard algorithm like RSA, incorrect usage can lead to serious security vulnerabilities. Here are 5 practical tips to help you avoid common pitfalls:

① Always use secure padding schemes: Prefer RSA-OAEP (not RSA-PKCS1-v1_5) for encryption, and prefer RSA-PSS (not PKCS#1 v1.5 signing) for signatures. PKCS#1 v1.5 has known padding oracle attack risks; several historical vulnerabilities (such as the 2012 Lucky Thirteen and 2014 Bleichenbacher descendant attacks) targeted it.

② Manage private keys properly, never hardcode: The private key is the heart of RSA security. Never hardcode private keys in source code, config files, or frontend JavaScript. Recommended options include key management systems (KMS such as AWS KMS, HashiCorp Vault), hardware security modules (HSMs), operating system-provided keychains, or cryptographically secure key derivation functions (such as PBKDF2, scrypt, argon2) to derive keys from passphrases. Keys must be rotated periodically and access minimized.

③ Use hybrid encryption, don't encrypt large files with RSA: RSA can only encrypt data smaller than the modulus n, and it's relatively slow. The standard approach: generate a random AES key, encrypt this AES key with the RSA public key, then encrypt the actual data with AES (this is hybrid encryption). The receiver decrypts the AES key with the RSA private key before decrypting the data. Our AES tool can be used for the symmetric encryption portion.

④ Use audited crypto libraries, don't implement RSA yourself: Never implement RSA (or any cryptographic primitive) yourself. Use widely audited and tested standard libraries: the Web Crypto API (window.crypto.subtle) or crypto-js / node-forge in JavaScript, javax.crypto in Java, the cryptography module in Python, or the crypto/rsa package in Go. These implementations have been validated by millions of developers.

⑤ Ensure key generation uses cryptographically secure randomness: When generating p and q, always use the operating system's cryptographically secure pseudo-random number generator (CSPRNG), such as crypto.getRandomValues() in browsers, crypto.randomBytes() in Node.js, or /dev/urandom on Linux. Never use ordinary random number generators (like Math.random()) — their output is predictable and can lead to easily breakable keys.

🔒 Local Browser Processing: Our RSA tool runs entirely in your browser. All key generation, encryption, and decryption operations are performed locally in the JavaScript engine. Your plaintext, ciphertext, public keys, and private keys are never uploaded to any server, nor are they recorded in any logs. The tool works even without an internet connection.

🛡️ Safe Usage Recommendations: When handling sensitive data with this tool, we recommend using privacy mode with browser extensions disabled, and ensuring your device is free of malware. Do not process highly sensitive information on public or untrusted computers. Clear your browser cache after use and close the page.

⚡ High-Performance Computing: RSA key generation is relatively slow, but encryption and decryption speeds are more than sufficient for daily development and testing. Our tool uses a standard JavaScript implementation that can generate 2048-bit keys in seconds on a typical laptop.

🌐 Open Source & Transparent: We use industry-standard encryption implementations, with algorithm logic fully transparent to all users, ensuring no hidden behavior. Data security and privacy are our core commitments.

⚠️ Legal Compliance Notice: Please ensure you comply with the laws and regulations of your country and region when using this tool. This tool is intended for legal data protection, development testing, and learning research purposes only. Any use for illegal purposes is strictly prohibited.

💡 Final Reminder: Cryptography is a deep discipline. This article provides conceptual introduction and practical advice and cannot replace professional security auditing. When deploying encryption schemes in production systems, we strongly recommend consulting professional cryptographers or security engineers. Our online RSA tool can assist you in daily development and learning, but production environment security requires systematic protection.