James A. Donald wrote: > On 2010-07-14 4:12 PM, Eric Norman wrote: >> If I understand the alleged attack correctly, it depends on the timing >> difference if a standard >> byte sequence comparison is "optimized" by exiting as soon as two >> bytes differ. >> >> Has code been written that actually demonstrates that this can be >> effective? That is, has code >> been written to demonstrate that the time to execute, for instance, >> about two instructions >> between failure of the byte comparison at the first byte and failure >> at the second byte can >> actually be detected over a network? > > While timing leaks need to be fixed as a matter of policy, perhaps by > starting the compare at a random point within the token, this is not a > real leak, since the timing difference is nanoseconds, and routing > jitter is milliseconds
Starting the compare at a random point is much more difficult and error-prone than implementing a constant-time compare function. Please see Taylor's original note, which included such a constant-time function. You are incorrect about both the timing delta and unfiltered jitter. The timing delta is much more than nanoseconds in languages such as Java and Ruby. We will give the hard numbers at our talk. For jitter, please see my reply to Eric this morning giving old research results of 20 microseconds unfiltered jitter on the WAN and 100 nanoseconds on the LAN. You can measure deltas well below the round-trip time with proper filtering. The whole point of our talk, really, is to clear up misconceptions such as these with experimental results. Thanks, -- Nate Lawson Root Labs :: www.rootlabs.com +1 (510) 595-9505 Solving embedded security, kernel and crypto challenges _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
