2 ms·
Yes, I don't see that being detectable for things like web-based APIs. For these string lengths (eg., HMAC with SHA-256), the network lag would add sufficient r
by lobster_johnson 14y ago
Yes, I don't see that being detectable for things like web-based APIs. For these string lengths (eg., HMAC with SHA-256), the network lag would add sufficient randomness that you would not be able to measure any difference in timings in the string comparison.
- tptacek 14y agoIt turns out that it is possible, over a WAN, on some frameworks. The rule of thumb is, if the comparison is effectively being done by libc's memcmp(), the timing attack is very difficult to do even across a single switch; however, some platforms don't drop to memcmp and instead compare each byte explicitly. These are timeable. If you're wondering, "how do I detect nanosecond differences over a network when my measurement will be swamped by other things happening on the target, the network, and my host", the answers boil down to: * You're going to move your measurement code as close to the drivers as possible, and fix interrupt handling so that interrupts don't confound your measurements. * You're going to get yourself on the same hosting provider as your target; for instance, a good chunk of all target apps can be attacked via Amazon EC2 for not very much money. * You're going to take lots and lots and lots and lots of measurements and then use high school statistics to process the results.
- jcoglan 14y agoI realize it seems impossible, but it's been done, repeatedly. https://www.google.co.uk/search?q=timing+attacks+over+the+internet https://www.google.co.uk/search?q=timing+attacks+over+the+in...