$10 says it would become unstuck anyway ;). Implementors/Developers already need intelligence and skill for stacks of other security issues - this one is simpler by far to fix than most.
A delay based fix seems a bit overly specific/complex. Would you not have to time positive conditions across a wide variety of systems and environments on an individual basis in order to apply an appropriate delay to the error condition? I don't see many higher level languages, at least, heading down that road. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team ________________________________ From: Phillip Hallam-Baker <[email protected]> To: Breno de Medeiros <[email protected]> Cc: Pádraic Brady <[email protected]>; openid-security <[email protected]> Sent: Fri, July 16, 2010 7:02:18 PM Subject: Re: [security] Widespread Timing Vulnerabilities in OpenID implementations That would seem to me to point to a more general fix. I don't like fixes that depend on the skill and intelligence of the implementer. They tend to come unstuck. Fixing this timing bug is good, but how many others are there? A much easier fix to implement and one that would have general applicability against timing attacks would be to insert a delay before returning an error condition. This has the additional benefit of slowing down the attacker. I record the time I receive a packet as a matter of course. It would not be difficult to write some code that ensures that the time take to return an error is quantized at a pretty coarse level (10ms or so). On Fri, Jul 16, 2010 at 12:41 PM, Breno de Medeiros <[email protected]> wrote: > On Fri, Jul 16, 2010 at 08:02, Pádraic Brady <[email protected]> wrote: >> I can only speak for PHP, but the function is also multiples slower than a >> native comparison from when I was implementing it last year. Not all that >> surprising given PHP is also built on C (to the point it practically copies >> functions) so it should resolve similarly. > > The only fair comparison here is when the two inputs are equal. > Lengthening the time of computation when the inputs are different is > the goal of this fix. > >> >> Just on implementations - have you notified these directly? Not all of them >> may be paying attention to this list since it's not necessarily >> implementation specific. >> >> Paddy >> >> Pádraic Brady >> >> http://blog.astrumfutura.com >> http://www.survivethedeepend.com >> Zend Framework Community Review Team >> >> >> ________________________________ >> From: Nate Lawson <[email protected]> >> To: Andrew Arnott <[email protected]> >> Cc: openid-security <[email protected]> >> Sent: Fri, July 16, 2010 12:20:36 AM >> Subject: Re: [security] Widespread Timing Vulnerabilities in OpenID >> implementations >> >> 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 >> >> _______________________________________________ >> security mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-security >> >> _______________________________________________ >> security mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-security >> >> > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > _______________________________________________ > security mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-security > -- Website: http://hallambaker.com/
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
