[security] Widespread Timing Vulnerabilities in OpenID implementations

[Nate Lawson]

Andrew Arnott wrote:
> These six lines of code turn out to be ~*100 times slower* than the built-in
> .NET String.Equals function.  I don't know why there is such a perf
> difference, but apparently .NET has some serious string equality check
> optimizations in their native code.  Has anyone else compared the
> performance of their language's native string equality check function and
> this hand-written alternative?

We're doing that as part of our talk. Did you compare 100% correct
strings or were they different? Obviously, a compare that terminates
early will be faster for non-matching input.

When you say 100x slower, what are your actual numbers in terms of
nanoseconds per byte for each version?

In Python, a string compare with == devolves to a call to C memcmp(). I
suspect .NET does the same thing. For Java and Ruby, it doesn't and so
the routine Taylor posted is nearly identical in performance to the
naive compare.

I'm sure the secret_cmp() function could be subject to some
language-specific optimizations for non-native environments. It's worth
looking into.

-- 
Nate Lawson
Root Labs :: www.rootlabs.com
+1 (510) 595-9505 / (415) 305-5638 mobile
Solving embedded security, kernel and crypto challenges