All in the timing: How side channel attacks work
summary
Shows that Python string == compares left to right so an attacker can recover an 8‑char secret in 144 tries by measuring response time, that Google Keysar HMAC check gets fixed in 2009 by switching to a constant‑time compare (use hmac.compare_digest), that gzip compression lets an attacker guess a CSRF token in under 30 seconds with ~95% accuracy by length leakage, that randomized hash seeds (PEP 456) and Meltdown’s speculative‑execution cache timing are practical exploits.
AI-written summary · about
chapters (13)
- 0:00Start
- 0:50Overview of What Side Channel Attacks Are
- 2:53Login Forum
- 7:30Constant Time Operation
- 10:54Disable Gzip Compression
- 11:33Django's Cross-Site Request Forgery Protection
- 11:44Cross-Site Request Forgery
- 14:02How To Figure Out the Cross-Site Request Forgery Token
- 16:05Attack on Timing
- 19:47Virtual Memory
- 23:07Speculative Execution
- 25:05Philip James
- 27:09Cryptographic Hash Function
related talks
14mProtecting cryptography code from timing vulnerabilities
51mTiming Attacks Have Never Been So Practical: Advanced Cross-Site Search Attacks
50mTime Trial: Racing Towards Practical Timing Attacks
30mMy code is being hacked!
40m"It Me": Under the Hood of Web Authentication
01h 02mCryptographic Side-Channels on Embedded Devices
42mBreak Crypto like a Pro!
26mLoophole: Timing Attacks on Shared Event Loops in Chrome