[steveitis]

Only by introducing a delay where is none is needed.

This makes things slower for the rest of us. 1 extra millisecond per user * 8 billion users * times 10 logins a day == Lots Of Lost Man Hours, probably enough to rebuild the great pyramids of Egypt by hand every year.

Security researchers are the reason we can't have nice things. :)

[tptacek]

The funniest part about these discussions is that we're discussing an optimization that exclusively helps attackers. Virtually all HMAC candidate hashes are correct all the way through the final byte, meaning that even in a classic short-circuited compare, you still have to read everything. In virtually all traffic, you never get to take that short circuit. The only time short-circuited comparisons ever make things faster is when an attacker is waiting for a rejection.

[gmonroe]

However, in many high-level languages == is written in C, and reimplementing it in the high-level language can be quite slow in comparison.

[caf]

You know, it'd be handy if such high-level languages implemented a separate =$= operator that worked just like ==, but was timing-independent.