<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt">$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.<br>
<br>
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.<br>
<br>
Paddy<div> </div><span style="color: rgb(0, 0, 191);"><font style="font-family: times new roman,new york,times,serif;" size="3"><span style="font-weight: bold;">Pádraic Brady<br><br></span></font><span style="font-style: italic;"><font style="font-family: times new roman,new york,times,serif;" size="3"><a rel="nofollow" target="_blank" href="http://blog.astrumfutura.com/">http://blog.astrumfutura.com</a><br><a rel="nofollow" target="_blank" href="http://www.survivethedeepend.com/">http://www.survivethedeepend.com</a><br><u><font color="#0000ff"><a rel="nofollow" target="_blank" href="http://framework.zend.com">Zend Framework Community Review Team</a></font></u><br></font></span></span><div><br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: tahoma,new york,times,serif; font-size: 8pt;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b>
Phillip Hallam-Baker <hallam@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> Breno de Medeiros <breno@google.com><br><b><span style="font-weight: bold;">Cc:</span></b> Pádraic Brady <padraic.brady@yahoo.com>; openid-security <openid-security@lists.openid.net><br><b><span style="font-weight: bold;">Sent:</span></b> Fri, July 16, 2010 7:02:18 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [security] Widespread Timing Vulnerabilities in OpenID implementations<br></font><br>
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><br><br>On Fri, Jul 16, 2010 at 12:41 PM, Breno de Medeiros <<a ymailto="mailto:breno@google.com" href="mailto:breno@google.com">breno@google.com</a>> wrote:<br>> On Fri, Jul 16, 2010 at 08:02, Pádraic Brady <<a
ymailto="mailto:padraic.brady@yahoo.com" 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><span>>> <a
target="_blank" href="http://blog.astrumfutura.com">http://blog.astrumfutura.com</a></span><br><span>>> <a target="_blank" href="http://www.survivethedeepend.com">http://www.survivethedeepend.com</a></span><br>>> Zend Framework Community Review Team<br>>><br>>><br>>> ________________________________<br>>> From: Nate Lawson <<a ymailto="mailto:nate@rootlabs.com" href="mailto:nate@rootlabs.com">nate@rootlabs.com</a>><br>>> To: Andrew Arnott <<a ymailto="mailto:andrewarnott@gmail.com" href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>>> Cc: openid-security <<a ymailto="mailto:openid-security@lists.openid.net" 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 target="_blank" href="http://www.rootlabs.com">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 ymailto="mailto:security@lists.openid.net" href="mailto:security@lists.openid.net">security@lists.openid.net</a><br><span>>> <a target="_blank"
href="http://lists.openid.net/mailman/listinfo/openid-security">http://lists.openid.net/mailman/listinfo/openid-security</a></span><br>>><br>>> _______________________________________________<br>>> security mailing list<br>>> <a ymailto="mailto:security@lists.openid.net" 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 ymailto="mailto:security@lists.openid.net" 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><span>Website: <a target="_blank" href="http://hallambaker.com/">http://hallambaker.com/</a></span><br></div></div>
</div></body></html>