Timing attacks reveal the secret keys used by secure communication channels, and are particular pernicious because they can occur online - often without detection. In essence the time of an activity can reveal the secret keys that power public key crypto, for example when an HMAC is given an incorrect key it can take a different amount of time depending on how much of the key is incorrect (with more correctness taking a longer period of time since more comparisons occur before inequality is detected). This is the naïve timing attack; there are much more sophisticated versions that could theoretically detect differences even when one has supposedly constant-time algorithms. It is these sophisticated cases about which we are particularly concerned.
An excellent talk on this topic is: Black Hat USA 2010: Exploiting Timing Attacks in Widespread Systems by Lawson/Nelson. While not the most up-to-date publication, the information in that talk remains relevant and forms the basis for the numbers and assertions in this question.
The significance of timing attacks cannot be overstated. Not long before the presentation the vast majority of civilian encrypted http/web based communication was vulnerable to these timing attacks, essentially meaning that there were no secret communications over the web. Much effort has been made to fix these attacks, with the most common solution being constant-time comparisons of the sort referred to in
Because these attacks occur over the network, there is a lot of jitter. One model to weed out the jitter and get to the raw timings is to use a "box model" t-test that chops off the top and bottom percentiles of the data in terms of response-time. Owing to the automation, the sample sizes can be astronomically large, as the vast majority of potential targets do not test for or block the type of failures that reveal these secrets.
So the essential question would seem to be: Can one detect, based on how many ns it takes to perform a comparison, whether one is comparing equal or inequal strings of characters. A bad compare function will have wildly different run-times depending on the difference in string lengths and the position of the first inequal character, but a good function ought to have effectively indistinguishable run-times (i.e. it should call the exact same instructions, and they should not be optimized away by the compiler/CPU/cache).
We can generate with significant precision the timings of the local compare functions, in the example case with process.hrtime, which gives us the ns (and we do not have to deal with the network jitter, but there will be variation).
The Black Hat 2010 conference indicated that timings as little as 15ns are detectable with 9,000 samples over even jittery networks with sufficient samples. Additional samples similarly eliminate the benefit of adding random delays. One ought to presume that attackers will have essentially unlimited samples.
@whuber suggested the following as the test:
all strings have
- comparable mean processing times; and
- comparable timing variations; and
no strings ever will be processed in unusually short times.
Subject to further input and clarification, I believe this is essentially correct. The second question is easy to answer, but the first question is more difficult.