On Fri, Jul 16, 2010 at 2:02 PM, Phillip Hallam-Baker <[email protected]> wrote: > insert a delay before returning an error condition. > This has the additional benefit of > slowing down the attacker.
+1 bob wyman On Fri, Jul 16, 2010 at 2:02 PM, Phillip Hallam-Baker <[email protected]>wrote: > 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 >
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
