<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"><DIV></DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Paddy<BR> </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 href="http://blog.astrumfutura.com/" target=_blank rel=nofollow>http://blog.astrumfutura.com</A><BR><A href="http://www.survivethedeepend.com/" target=_blank rel=nofollow>http://www.survivethedeepend.com</A><BR><U><FONT color=#0000ff><A href="http://framework.zend.com/" target=_blank rel=nofollow>Zend Framework Community Review Team</A></FONT></U><BR></FONT></SPAN></SPAN>
<DIV><BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR>
<DIV style="FONT-SIZE: 8pt; FONT-FAMILY: tahoma, new york, times, serif"><FONT face=Tahoma size=2>
<HR SIZE=1>
<B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Nate Lawson <nate@rootlabs.com><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> Andrew Arnott <andrewarnott@gmail.com><BR><B><SPAN style="FONT-WEIGHT: bold">Cc:</SPAN></B> openid-security <openid-security@lists.openid.net><BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Fri, July 16, 2010 12:20:36 AM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [security] Widespread Timing Vulnerabilities in OpenID implementations<BR></FONT><BR>Andrew Arnott wrote:<BR>> These six lines of code turn out to be ~*100 times slower* than the 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" ymailto="mailto:security@lists.openid.net">security@lists.openid.net</A><BR>http://lists.openid.net/mailman/listinfo/openid-security<BR></DIV></DIV></div></body></html>