Textbook RSA
NEVER USE DIRECTLYRSA in its raw form: real primes, real modular exponentiation, real key generation — but no padding. See exactly why determinism makes textbook RSA completely insecure.
Step 1 — Generate RSA Key Parameters
Generate real prime numbers p and q, then compute all RSA parameters step by step. Use small primes (~32-bit) for visual clarity, or 256-bit primes (a 512-bit modulus) to see the numbers grow. Both are teaching sizes: this panel's key generation is naive BigInt Miller-Rabin, not production keygen. Real 2048/4096-bit RSA lives in the OAEP and PSS panels, where WebCrypto generates the keys. The chain below turns the two secret primes into a public lock (n, e) and a private key (d) via φ(n), and the whole point of modular exponentiation is that it only inverts if you know d.
Why this congruence matters: encrypting raises m to the e-th power, decrypting raises the result to the d-th power, so decryption computes m(e·d). Euler's theorem says that whenever e·d ≡ 1 (mod φ(n)), that giant exponent collapses back to m1 = m. In plain terms, d is exactly the exponent that undoes e — and you can only compute d if you know φ(n), which needs the secret primes p and q. That is the trapdoor, made concrete.
Feel the Trapdoor — Try to Factor n
The public number n is public. If an attacker could split it back into its two secret
primes p and q, they could rebuild your private key d and read everything. RSA's entire security is
the bet that nobody can. Below, factor the small demo n yourself — then see the cost of
doing the same to a real 2048-bit key.
Step 2 — Encrypt and Decrypt
Encrypt: c = me mod n | Decrypt: m = cd mod n
Determinism Demonstration
Encrypt the same message twice. The ciphertext is always identical — a fatal flaw.
Side-by-Side — Textbook vs OAEP, Same Plaintext, Twice Each
Encrypt the same plaintext twice with textbook RSA and twice with RSA-OAEP. Compare byte-by-byte. Textbook collides on every byte (deterministic). OAEP differs on every byte (randomized). This is the single picture that makes "use OAEP" non-negotiable.
Why Textbook RSA Is Broken
- Deterministic: Same plaintext always → same ciphertext. Attacker can build an encryption oracle and test known messages.
- Homomorphic weakness: c₁ · c₂ mod n = Enc(m₁ · m₂) — ciphertexts can be multiplied to produce the encryption of the product.
- Small message space: Low-entropy messages (like symmetric keys) are vulnerable to brute-force with an encryption oracle.
- No ciphertext integrity: Any integer is a valid ciphertext — malleability attacks are trivial.
RSA-OAEP: Secure Encryption
RECOMMENDEDRSA-OAEP (Optimal Asymmetric Encryption Padding) adds randomization and domain separation to make RSA encryption semantically secure (in fact IND-CCA2). Specified in RFC 8017 (PKCS#1 v2.2), Section 7.1.
Generate RSA Keys via WebCrypto
Real 2048-bit and 4096-bit RSA key pairs generated using the browser's WebCrypto API. NIST SP 800-57 recommends 2048-bit minimum; 3072-bit or 4096-bit for long-term security. The figures below are classical security strengths from SP 800-57 Part 1 Rev. 5. That is a different scale from the NIST PQC security categories used in the comparison table further down — no RSA key size reaches PQC category 1, because Shor's algorithm breaks RSA outright.
RSA-2048
~112-bit classical security (SP 800-57 security strength 112)
RSA-4096
~140-bit classical security (between SP 800-57's 128- and 192-bit levels)
Encrypt with RSA-OAEP-SHA-256
The plaintext is padded with OAEP before RSA encryption. Each encryption uses a fresh random seed.
Randomization — Same Plaintext, Different Ciphertexts
Unlike textbook RSA, OAEP uses a random seed. Encrypt the same message twice and compare — ciphertexts are always different, providing IND-CPA security.
OAEP Padding Structure
At the highest level, OAEP does one job: take your message plus a fresh random seed and scramble them together into one block where every output byte depends on every input byte. Change a single bit of the message or the seed and the entire block changes — so two encryptions of the same message look completely unrelated, and an attacker can't peel off or tamper with any piece.
Press the button to change a single input byte. Watch how many output bytes change — that all-or-nothing spread is called the avalanche effect.
Show the full byte-field structure (maskedSeed, maskedDB, MGF1 masks)
Under the hood, that scramble is two MGF1 mask operations driven by the random seed, producing non-determinism and all-or-nothing decoding.
After you run an OAEP encryption above, hover any colored segment to see the actual bytes from that operation.
Decrypt
RSA-PSS: Secure Signatures
RECOMMENDEDRSA-PSS (Probabilistic Signature Scheme) adds a random salt to each signature, making it provably secure in the random oracle model. Specified in RFC 8017 §8.1.
Generate Key and Sign
Sign a message with RSA-PSS-SHA-256. Each signature uses a fresh random salt (sLen = 32 bytes).
Verify Signature
Test signature verification with correct and tampered messages.
PSS Padding Structure
PSS encodes the message hash with a random salt. The salt makes signatures non-deterministic and provides tight security reduction.
After you sign a message above, hover any colored segment to see the actual bytes from that signature.
PSS vs PKCS#1 v1.5 Signatures
Why PSS is the provably secure choice.
| Property | PKCS#1 v1.5 (RSASSA-PKCS1-v1_5) | PSS (RSASSA-PSS) ✓ |
|---|---|---|
| Randomization | Deterministic | Probabilistic (random salt) |
| Security proof | No tight reduction known | Tight reduction to RSA inversion |
| Signature malleability | Potentially malleable | Non-malleable by design |
| NIST recommendation | Legacy — not recommended for new systems | Recommended (FIPS 186-5) |
| TLS 1.3 | PKCS#1 v1.5 signatures still allowed | PSS signatures preferred |
Small Exponent Attack — Håstad Broadcast
PADDING IS NON-NEGOTIABLEIf the same unpadded message m is sent to three recipients all using e=3, an attacker who intercepts all three ciphertexts can recover m using the Chinese Remainder Theorem and integer cube root — no private key needed.
Pick Your Config — Will Your Message Survive?
You're sending a short message to three recipients. You get to pick how it's encrypted. Click a configuration and the demo runs the broadcast and the attack on your choice.
Setup — Three Recipients, e=3 (Manual)
Generate three independent RSA keys each with e=3 and distinct small moduli. These represent three servers all using textbook RSA with a small public exponent.
Broadcast Same Message Unpadded
Encrypt the same message to all three recipients with no padding: cᵢ = m³ mod nᵢ. The attacker intercepts all three ciphertexts.
Attack — CRT Reconstruction + Cube Root
Since m < nᵢ for all i, we have m³ < n₁·n₂·n₃. The Chinese Remainder Theorem gives us exactly M = m³. Then the integer cube root of M reveals m directly.
Real-World Receipts — Small-Exponent / Coppersmith Failures
Low-exponent and broadcast attacks aren't just academic. Each row below shipped in production code.
Why OAEP Destroys This Attack
- Randomization: With OAEP, each recipient receives a different padded message. Even with the same underlying plaintext, the padded m values differ, so m³ values are not related by CRT.
- Structure: The OAEP padding expands the message to fill the full modulus, so m is always close to n in size — m³ mod n wraps around the modulus multiple times.
- Public exponent: FIPS 186-5 requires 216 < e < 2256, and e=65537 is the universal choice for production RSA. Small e values (e=3, e=17) must only ever be used with proper padding.
Bleichenbacher PKCS#1 v1.5 Oracle
PKCS#1 v1.5 ENCRYPTION = AVOIDBleichenbacher (1998) showed that a single-bit padding oracle — "is this ciphertext PKCS#1 v1.5 conformant?" — is enough to decrypt any RSA ciphertext via adaptive chosen-ciphertext queries. This broke SSL/TLS RSA key exchange and is still discovered in the wild today (ROBOT, 2017).
Research update: Reverse-Bleichenbacher (October 2026)
Lü et al. recover the least significant secret bytes first and stop once the target secret is recovered, rather than spending queries recovering the entire padding block. Their paper reports experiments with 2048-bit RSA and a standards-conforming PKCS#1 v1.5 oracle, targeting legacy TLS RSA key exchange. The attack requires an exploitable decryption oracle; it is not a general factoring result or a break of OAEP, PSS, or TLS 1.3 key exchange.
This browser runs the classical full-plaintext interval attack on 128-bit RSA with a weaker oracle that
checks only the leading 00 02 bytes. It does not implement Reverse-Bleichenbacher or reproduce
the paper’s performance measurements. Disable legacy TLS RSA key exchange and remove PKCS#1 v1.5
decryption-oracle leakage in real deployments.
PKCS#1 v1.5 Encryption Padding Structure
A PKCS#1 v1.5 conformant encryption block has a specific structure. The oracle leaks only one bit: whether the decryption starts with 0x00 0x02.
"Conformant" means: EM[0] == 0x00 AND EM[1] == 0x02.
This is equivalent to: m ∈ [2B, 3B−1] where B = 28(k−2), k = modulus byte length.
Setup — Small RSA for Demonstration
Generate a small RSA key (128-bit modulus, 16 bytes) to make the attack completable in the browser. Bleichenbacher's 1998 paper tested the attack against 512-bit and 1024-bit keys, needing between 300 thousand and 2 million chosen ciphertexts; its "million message" estimate of roughly 220 queries is the figure for a 1024-bit modulus.
The Padding Oracle
The oracle accepts a ciphertext and returns only "conformant" or "not conformant." In real attacks, this oracle was exposed via error messages in TLS handshakes.
Execute Bleichenbacher Attack
The attacker never decrypts anything. Their only lever is a property RSA gives for free: multiplying
two ciphertexts multiplies the plaintexts inside them. So if the attacker multiplies the
intercepted c by se, the hidden plaintext quietly becomes
m × s — a value they chose the multiplier for, even though they can't see it. That is
what lets them probe m through the padding oracle. Watch it on two small numbers, using
this demo's real key:
Now the attack itself. It multiplies c by se mod n, where varying s shifts the decryption
to m × s. Each conformant result tells the attacker m × s landed in the
valid-padding window, which constrains the interval [a, b] containing m — so the bar below shrinks
not by magic, but as a direct consequence of the lever above.
EM[0] == 0x00 AND EM[1] == 0x02.
a and b agree on that byte and every byte before it — a shared
prefix is what pins a byte down, since a single matching byte deep in the interval proves nothing while
a higher byte can still carry. Watch them light up left to right as the interval shrinks — by the time
you see "Hi!" the attack is over.
Real-World Receipts — Bleichenbacher in Production
The "million message attack" was first published in 1998. Variants have shipped in production TLS stacks every few years since. The countermeasures are hard.
Why TLS 1.3 Removed RSA Key Exchange Entirely
- No forward secrecy: RSA key exchange uses the server's long-term private key to wrap the session key. Compromise of the private key retroactively decrypts all past traffic.
- Bleichenbacher variants: ROBOT (2017) reported vulnerable products from at least eight vendors and open source projects still vulnerable 19 years after the original paper, and the disclosure table has since reached 21 affected vendors and products. The oracle is hard to eliminate from real implementations.
- TLS 1.3 fix: RSA key exchange (RSA_PSK, RSA) removed. Only ephemeral Diffie-Hellman (ECDHE) allowed — provides forward secrecy by design.
- PKCS#1 v1.5 encryption: RFC 8017 explicitly marks RSA-PKCS1_V1_5 encryption as legacy. Use RSA-OAEP for any new RSA encryption.
Oracle Without Factoring — √eNFS (2026)
DELAYED-TARGET RSAShea, Haller, Suhl, Heninger, and Thomé showed that a temporary raw-RSA oracle can be used to produce an e-th root for random targets without factoring N or recovering the private key. This is the delayed-target RSA model in §1 and §2 of ePrint 2026/2131, with the precise oracle/games in Fig. 6 and the one-more RSA comparison in §5. The paper is explicit that this is not plain RSA inversion, not ordinary factoring, and not a general one-more RSA break.
Threat model: delayed-target RSA (DT-RSA) vs OM-RSA
- Order of events: public key and precomputation first, then temporary access to a raw RSA signing oracle for approximately 4.07 billion oracle queries.
- Oracle access ends; the attacker is then given a random target t and must produce t1/e mod N offline.
- Forgery can be repeated offline for any target after the oracle window closes.
- The private key and primes are not recovered; the paper's point is the temporary ability to forge chosen targets without factoring the modulus.
- One-more RSA is a different chosen-target/one-more inversion assumption used in blind-signature proofs.
- In the paper's §5 discussion they show √eNFS solves DT-RSA, while a straightforward adaptation for OM-RSA is much worse than GNFS.
- Their point is precise: √eNFS does not solve plain RSA, factoring, or (efficiently) one-more RSA.
Complexity: √eNFS vs GNFS vs SNFS
The paper uses the same LN(1/3, c) notation as the classical factoring literature. For this attack the relevant costs are: √eNFS = LN(1/3, 1.577), GNFS = LN(1/3, 1.923), and SNFS = LN(1/3, 1.526). The reason is that sieving is one-sided: the “other side” is traded for a large number of oracle queries, exactly as discussed in §3.1.
Pipeline: from precomputation to forgery
The attack pipeline matches Fig. 3 and the timeline in Fig. 4: public key and precomputation first → temporary oracle access (approximately 4.07 billion raw-RSA queries) → oracle access ends → target arrives → offline forgery (descent, linear algebra mod e, e-th root in the number field).
LIVE VERIFICATION — real math from §4
The paper gives the exact public key and forgery example in §4. This is the 1024-bit HSM test key they forged against; §4.5 states the researchers generated the key outside the HSM and imported it. The button below verifies the published equation s65537 mod N = t; it does not rerun the number-field sieve computation or independently establish how the paper derived s.
Security table (Fig. 7) and caveats
| Key length | GNFS bit security | √eNFS bit security | Oracle queries |
|---|---|---|---|
| 1024 | 80 | 65 | 232 |
| 2048 | 112 | 90 | 243 |
| 3072 | 128 | 105 | 251 |
| 4096 | 144–152 | 119 | 257 |
The paper explicitly says these are extrapolated security estimates and that the costs are upper bounds (§6). The takeaway is not “RSA is dead tomorrow,” but that in this model, 2048–4096-bit RSA falls short of a 128-bit security target even before considering ordinary factoring or the usual signature security reductions.
Who is exposed? What is not.
- Exposed in practice: HSM raw-operation configurations and blind-RSA deployments can create the kind of oracle the paper exploits, including PKCS#11
CKM_RSA_X_509behavior with FIPS mode off. This was the paper's actual oracle: Thales Luna K6 and remote Luna S750. That is a conditional exposure scenario, not proof that every RSA deployment is vulnerable. - Also exposed: RSA blind signatures: RFC 9474 RSABSSA, Privacy Pass publicly-verifiable tokens, iCloud Private Relay, GNU Taler RSA-FDH.
- Bleichenbacher chaining: a PKCS#1 v1.5 padding oracle can be used to answer each raw query, so an attacker can maintain decryption ability after the bug is patched. This is the link back to the Bleichenbacher section above (§7.3).
- Not exposed by default: normal PKCS#1 v1.5 / PSS signing is not, by itself, the raw oracle this attack needs. The paper separately discusses the padded/AMR variant in §5.2, which is a distinct and more expensive setting; it does not imply that all padded RSA signing is categorically safe or categorically broken. The results also do not carry to ECDSA or Ed25519.
Toy live piece: raw-oracle malleability at teaching size
This is not √eNFS. It is a tiny sanity check of one exact malleability ingredient the paper exploits at scale: if a raw RSA oracle signs m₁ and m₂, then it also implicitly signs m₁·m₂. Here the browser does only the textbook arithmetic the attack relies on; it is not a replica of the full 1,380 core-year computation.
Honesty panel
- Academic CPUs only: no GPUs, no AI assistance in the attack itself. The authors estimate 2–9 GPU-years for 1024-bit with GPU sieving (§1.3).
- Publication status: the paper was published on ePrint on Sept. 20, 2026 and is still a preprint at the moment of writing; the paper is a research result, not an emergency patch note.
- Takeaway: the authors say this is not immediate alarm for most deployments, but that 2048–4096-bit RSA falls short of a 128-bit security target in this delayed-target model (§6); the estimate is an extrapolation, not a general factoring breakthrough.
RSA vs ECC vs Post-Quantum
QUANTUM-VULNERABLERSA security rests on the integer factorization problem. Shor's algorithm (1994) factors integers in polynomial time on a quantum computer, breaking all RSA key sizes. NIST's PQC standardization is complete — migration should begin now.
Algorithm Comparison (2026 NIST Recommendations)
| Algorithm | Key Size | Ciphertext / Sig Size | Classical Security | Post-Quantum Security | Status |
|---|---|---|---|---|---|
| RSA-2048 | 2048-bit (256 B public) | 256 B | ~112-bit | ❌ Broken (Shor) | LEGACY |
| RSA-4096 | 4096-bit (512 B public) | 512 B | ~140-bit | ❌ Broken (Shor) | LEGACY |
| ECDH P-256 | 64 B (32 B compressed) | 64 B shared secret | ~128-bit | ❌ Broken (Shor) | TRANSITION |
| X25519 | 32 B | 32 B shared secret | ~128-bit | ❌ Broken (Shor) | TRANSITION |
| ML-KEM-768 (Kyber) | 1184 B public key | 1088 B ciphertext | > 180-bit | ✅ ~168-bit (NIST L3) | RECOMMENDED |
| ML-DSA-65 (Dilithium) | 1952 B public key | 3309 B signature | > 180-bit | ✅ ~168-bit (NIST L3) | RECOMMENDED |
Sources: NIST SP 800-57 Part 1 Rev. 5; FIPS 203 (ML-KEM); FIPS 204 (ML-DSA); NIST PQC Round 3 Report.
Public Key Size Comparison
RSA key sizes dwarf modern alternatives — post-quantum keys are larger than ECC but far smaller than RSA at equivalent security.
Bar lengths scaled to ML-KEM-768 (1184 B) = 100%. RSA-4096 has the same bar width as ML-KEM-768 but provides no post-quantum security.
Why TLS Doesn't Encrypt the Body With RSA — Live Timing
RSA-OAEP can only encrypt a few bytes per operation. To send a 1 MB payload you'd have to chunk it into thousands of RSA ops. Press the button to time three approaches on 1 MB of random data — your numbers, your browser, right now.
Shor's Algorithm — Why RSA Will Break
- Classical factoring: Best classical algorithm (GNFS) runs in sub-exponential time — about 2112 operations for RSA-2048. Secure against classical computers.
- Shor's algorithm: Reduces factoring to order-finding in polynomial time. Requires a fault-tolerant quantum computer with ~4,000 logical qubits for RSA-2048.
- 2026 timeline: No quantum computer currently capable of breaking RSA-2048. But "harvest now, decrypt later" — adversaries store encrypted traffic today to decrypt with future hardware.
- Migration urgency: NIST published FIPS 203/204/205 in August 2024. Systems with >10-year security requirements should migrate now.