Oracle

The problem

Many people, engineers included, believe that "we encrypt it with AES" means a message is safe. It doesn't. A well-documented attack called the padding oracle recovers a whole encrypted message without breaking the cipher. It only needs a server that says whether a message's padding was valid. That single yes or no, asked about 2,000 times per block, is enough to rebuild the text.

The attack is written up in dozens of places, and the write-ups don't change minds. A page of algebra doesn't make a reader feel that their AES is beside the point. Most existing animations of it also skip a false-positive check the attack needs. Many quietly hold the answer in a variable and play it back.

I built Oracle for engineers who need to understand why authenticated encryption exists, for security teachers who want a live demo, and for anyone judging whether I can implement cryptography correctly.

It is an educational demo and not an attack tool. It has no network code at all. A test searches the built bundle and fails the build if any network API appears in it, so its inability to attack a live server is a property of the build.

What I built

I sealed the secret where the screen can't reach it

One module creates the key, the message and the starting block, encrypts, and hands out only four things: the encrypted text, the starting block, a yes-or-no oracle, and a call counter. The key and the message never leave it. When a recovered letter appears on screen, the attack produced it. A test holds a known message in its own sealed scope, runs the real attack, and checks the recovered bytes match. The app proves it isn't cheating.

The oracle answers with one bit and nothing more

The oracle takes an encrypted message and returns true or false. There is no error detail, no timing and no hint about which byte failed. A richer answer would let the attack cheat and would misrepresent what an actual attacker sees. So the attack works from one bit, as the real one does.

I built the false-positive check and let readers break it

When recovering the last byte of a block, a naive attack can accept a lucky match and record the wrong byte. Every byte after it is then corrupted. The fix is to change an earlier byte and ask again. I implemented it and animated it as its own step. Readers can switch it off and watch the recovery break. A test confirms the naive version fails on a message built to trigger it.

I run the attack once and replay the recording

The attack engine has no interface code and no clock. It runs the whole attack in milliseconds and records every guess, every verdict, every double-check and the maths behind each recovered byte. The screen only shows a point in that recording. Scrubbing back and forth is free, the animation speed is independent of the maths, and any moment can be shared as a link.

I hand-wrote the cryptography

AES-128, SHA-256, HMAC, the CBC chaining mode and PKCS7 padding are all my own code, checked against the official test vector. The only runtime dependencies are React and its DOM renderer. The first plan used a precompiled AES module. I dropped it because hand-written code needs no binary to audit and no exception to the no-network rule.

Result

Oracle is live and public. Its main view is a four-row stack of bytes: what the attacker sent, what padding the oracle judged, the middle block, and the recovered text filling in right to left in gold. A toggle swaps real AES for a labelled toy cipher, and the attack recovers the same text at the same cost. Turning on encrypt-then-MAC makes every forged message fail before decryption, so no gold ever appears.

A second mode rewrites "user=guest" to "user=admin" in an encrypted message without the key. Recovery takes about 2,000 oracle calls per block, which matches the theoretical average. I built it in seven days in September 2026.