<div>On Fri, Jul 16, 2010 at 2:02 PM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:hallam@gmail.com">hallam@gmail.com</a>></span> wrote:<br></div><div>><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "> insert a delay before returning an error condition.</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">> This has the additional benefit of<br>> slowing down the attacker.</span><br><br></div><div>
+1</div><div><br></div><div>bob wyman</div><div><br><div class="gmail_quote">On Fri, Jul 16, 2010 at 2:02 PM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:hallam@gmail.com">hallam@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">That would seem to me to point to a more general fix.<br>
<br>
I don't like fixes that depend on the skill and intelligence of the<br>
implementer. They tend to come unstuck. Fixing this timing bug is<br>
good, but how many others are there?<br>
<br>
A much easier fix to implement and one that would have general<br>
applicability against timing attacks would be to insert a delay before<br>
returning an error condition. This has the additional benefit of<br>
slowing down the attacker.<br>
<br>
I record the time I receive a packet as a matter of course. It would<br>
not be difficult to write some code that ensures that the time take to<br>
return an error is quantized at a pretty coarse level (10ms or so).<br>
<div><div></div><div class="h5"><br>
<br>
On Fri, Jul 16, 2010 at 12:41 PM, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a>> wrote:<br>
> On Fri, Jul 16, 2010 at 08:02, Pádraic Brady <<a href="mailto:padraic.brady@yahoo.com">padraic.brady@yahoo.com</a>> wrote:<br>
>> I can only speak for PHP, but the function is also multiples slower than a<br>
>> native comparison from when I was implementing it last year. Not all that<br>
>> surprising given PHP is also built on C (to the point it practically copies<br>
>> functions) so it should resolve similarly.<br>
><br>
> The only fair comparison here is when the two inputs are equal.<br>
> Lengthening the time of computation when the inputs are different is<br>
> the goal of this fix.<br>
><br>
>><br>
>> Just on implementations - have you notified these directly? Not all of them<br>
>> may be paying attention to this list since it's not necessarily<br>
>> implementation specific.<br>
>><br>
>> Paddy<br>
>><br>
>> Pádraic Brady<br>
>><br>
>> <a href="http://blog.astrumfutura.com" target="_blank">http://blog.astrumfutura.com</a><br>
>> <a href="http://www.survivethedeepend.com" target="_blank">http://www.survivethedeepend.com</a><br>
>> Zend Framework Community Review Team<br>
>><br>
>><br>
>> ________________________________<br>
>> From: Nate Lawson <<a href="mailto:nate@rootlabs.com">nate@rootlabs.com</a>><br>
>> To: Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>
>> Cc: openid-security <<a href="mailto:openid-security@lists.openid.net">openid-security@lists.openid.net</a>><br>
>> Sent: Fri, July 16, 2010 12:20:36 AM<br>
>> Subject: Re: [security] Widespread Timing Vulnerabilities in OpenID<br>
>> implementations<br>
>><br>
>> Andrew Arnott wrote:<br>
>>> These six lines of code turn out to be ~*100 times slower* than the<br>
>>> built-in<br>
>>> .NET String.Equals function. I don't know why there is such a perf<br>
>>> difference, but apparently .NET has some serious string equality check<br>
>>> optimizations in their native code. Has anyone else compared the<br>
>>> performance of their language's native string equality check function and<br>
>>> this hand-written alternative?<br>
>><br>
>> We're doing that as part of our talk. Did you compare 100% correct<br>
>> strings or were they different? Obviously, a compare that terminates<br>
>> early will be faster for non-matching input.<br>
>><br>
>> When you say 100x slower, what are your actual numbers in terms of<br>
>> nanoseconds per byte for each version?<br>
>><br>
>> In Python, a string compare with == devolves to a call to C memcmp(). I<br>
>> suspect .NET does the same thing. For Java and Ruby, it doesn't and so<br>
>> the routine Taylor posted is nearly identical in performance to the<br>
>> naive compare.<br>
>><br>
>> I'm sure the secret_cmp() function could be subject to some<br>
>> language-specific optimizations for non-native environments. It's worth<br>
>> looking into.<br>
>><br>
>> --<br>
>> Nate Lawson<br>
>> Root Labs :: <a href="http://www.rootlabs.com" target="_blank">www.rootlabs.com</a><br>
>> +1 (510) 595-9505 / (415) 305-5638 mobile<br>
>> Solving embedded security, kernel and crypto challenges<br>
>><br>
>> _______________________________________________<br>
>> security mailing list<br>
>> <a href="mailto:security@lists.openid.net">security@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
>><br>
>> _______________________________________________<br>
>> security mailing list<br>
>> <a href="mailto:security@lists.openid.net">security@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> --Breno<br>
><br>
> +1 (650) 214-1007 desk<br>
> +1 (408) 212-0135 (Grand Central)<br>
> MTV-41-3 : 383-A<br>
> PST (GMT-8) / PDT(GMT-7)<br>
> _______________________________________________<br>
> security mailing list<br>
> <a href="mailto:security@lists.openid.net">security@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Website: <a href="http://hallambaker.com/" target="_blank">http://hallambaker.com/</a><br>
</font><div><div></div><div class="h5">_______________________________________________<br>
security mailing list<br>
<a href="mailto:security@lists.openid.net">security@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-security" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
</div></div></blockquote></div><br></div>