Home▸Cybersecurity▸Timing Attack Lab (2D): Cracking a Secret Through Response-Time Leaks

⏱️ Timing Attack Lab (2D): Cracking a Secret Through Response-Time Leaks

2D bar-chart version of the timing side-channel attack lab: a naive comparator stops at the first mismatch, so measured response times leak one byte of a secret at a time. Toggle constant-time comparison and network jitter to watch the leak appear and disappear.

Cybersecurity2DModerate60 FPS📱 Mobile-adapted⇄ 3D version
2d-cybersec-topic-112 ↗ Open standalone

This 2D companion drives the exact same timing side-channel mechanic as the 3D version — a real byte-by-byte comparator that returns early on mismatch, timed with performance.now() — through a flat bar-chart view: each of the 64 candidate bytes for the current position gets its own bar, the tallest bar is the attacker's best guess, and two extra sliders (network jitter and secret length) let you push the same real algorithm past the point where the timing signal survives the noise.

⚙ Under the hood

2D timing side-channel lab: a naive comparator leaks one byte of a secret at a time through measured response times, visualized as a 64-candidate bar chart; toggle constant-time comparison and network jitter to see the leak appear and disappear.

Canvas 2DCybersecurityTiming AttackSide-ChannelCryptography

2D · HTML5 Canvas 2D · 60 FPS target · runs fully client-side, no install

Why does a naive comparison leak timing information?

A byte-by-byte comparator that returns as soon as it finds a mismatch does less work — and takes less time — for a wrong guess than for one that shares more correct leading bytes with the real secret. Measuring that time difference across many candidate bytes reveals which one is more likely correct.

How does constant-time comparison fix it?

A constant-time comparator always inspects every byte of both inputs and combines the differences with a bitwise operation such as XOR, so its running time never depends on how many leading bytes match. The timing side-channel disappears.

What does the network jitter slider show?

Real attacks are noisy: network latency and OS scheduling add random jitter on top of the true comparator timing. Raising the jitter slider adds more of that noise, showing how much a timing signal can be buried before the byte-by-byte attack starts guessing wrong.

What did you find?

Add reproduction steps (optional)