Lion Cipher Lab
Break PKCS#1 v1.5 with Bleichenbacher's Padding Oracle
- Foundations
- Advanced
- ~90 min
- Free · no account required
Why it matters
PKCS#1 v1.5 RSA encryption padding is still deployed across the internet -- in TLS, in VPNs, in load balancers -- decades after Daniel Bleichenbacher showed in 1998 that a server which merely reveals whether a ciphertext was 'correctly padded' leaks enough to recover the plaintext one adaptive query at a time. In 2017 the ROBOT researchers re-found that exact oracle live in F5, Citrix, Cisco, and other production stacks, because the leak does not need to be an API that says yes/no -- a different TLS alert, a slightly different response time, or a distinguishable error message is enough. Once…
What you'll learn
- Implementing PKCS#1 v1.5 (type-2) RSA encryption padding by hand and seeing exactly what makes a block 'well-formed'
- Building a one-bit padding-validity decryption oracle and understanding why a single leaked bit is a total break
- Bleichenbacher's 1998 adaptive chosen-ciphertext attack: interval narrowing that recovers plaintext with no private key
- Why the ROBOT (2017) resurrection worked -- the oracle is rarely a literal API but a TLS alert, timing, or error-message difference
- The durable defence: RSA-OAEP, uniform/constant-time error handling (RFC 8017), and never reusing an RSA key for both signing and encryption
Steps in this lab
- What Bleichenbacher's attack is, in one breath
- Why one leaked bit is a total break (the idea before the code)
- Set up a clean workspace
- Build the toy: a 256-bit RSA key + PKCS#1 v1.5 padding
- Build the one-bit padding oracle and the target ciphertext
- Implement Bleichenbacher's interval-narrowing attack
- Run it: watch the interval collapse to the secret
- ROBOT (2017): the oracle is rarely a literal API
- The defence: OAEP, and 'make the error indistinguishable'
- The judgment call: why this bug outlived its own paper