
Timing attack, 6.66% faster - jessaustin
http://homakov.blogspot.com/2014/07/timing-attack-666-faster.html
======
tptacek
Doing 16 bits at a time instead of 8 isn't going to make Ruby string
comparison timing tractable; the timing difference you're looking at is less
than a nanosecond per byte, because Ruby's string comparison is essentially
just C memcmp. That's below the noise floor even on a LAN.†

Even for signals above the noise floor, ie, higher than the "WAN" threshold
Crosby and Wallach worked out, actually performing these attacks is very
difficult. Among other things, you'll probably need to goof around with your
network drivers and write your own timer code.

Timing attacks against simple string comparison might belong to a small class
of attacks that get _worse_ over time, not better, because networks do not get
less noisy as fast as computers get faster and shrink the signal.

Unfortunately, not all timing attacks devolve to simple string compare. Look
for instance at the Lucky 13 attack on TLS; the distinction being profiled
there isn't a single byte comparison, but rather entire invocations of a hash
core function.

† _Here 's a link to the most recent measurements I could find:
[http://twitter.com/tqbf/status/491607410537406465/photo/1](http://twitter.com/tqbf/status/491607410537406465/photo/1)
_

~~~
murbard2
For N large enough, there is no noise floor. In some cases, you could
realistically be attacking a system for months or years to obtain a key.

~~~
xyzzy123
There is the threshold at which each measurement is giving you less
information than brute-force. At that point, you can say "this is not
vulnerable to a timing attack" even if a timing side-channel is present.

The larger the search space, the more noise you would be willing to put up
with....

EDIT: I'm not sure what you mean by N. If you mean N as the size of the search
space rather than N as the number of requests, I agree with you!

~~~
murbard2
You actually do both. Each measurement induces a probability distribution over
the space upon which you bruteforce.

Also not that timing attacks are quadratic in the noise to signal ratio and
linear in key length which bruteforce is exponential in keylengths. So that
threshold is likely many orders of magnitude smaller than you imagine.

------
anuragbiyani
A server can easily add an extra random wait to all unauthorized responses,
making such attacks almost infeasible (at least for web-app case).

~~~
homakov
1) extra random is not going to help, in long term any "noise" disappears and
signal can be seen. 2) such attacks _are_ infeasible most of the time, so we
don't need to worry

~~~
anuragbiyani
I agree that actual "signal" can still be learned over time, but if we chose
additional random wait time from a distribution unknown to attacker (or even
better, randomly select the distribution itself, and shuffle often), we can
reduce the efficiency of attack dramatically.

But another possible way is to add a deterministic amount of additional wait
time (instead of random), i.e., "lie" about computation time of all inputs
consistently. If designed properly, this won't leak any signal (assuming the
strategy on how to "lie" is chosen randomly itself and shuffled often, so
attacker doesn't learn it).

Strategy of waiting for maximum time across all possible requests (as
mentioned in your post) is sort of a special case of this, where one
(deterministically) add a wait time of W - C (where W = Worst case time across
all inputs, and C = actual time taken for this input). But we can use a less
aggressive approach to hide the actual computation time as well.

------
squigs25
Another reason to hash your passwords!

~~~
tshadwell
Perhaps another reason to use a fixed time string equality function

~~~
yeukhon
You mean checking 123 == 1234 actually going through all 4 characters instead
of immediate stop?

~~~
mikeash
I believe it's OK to bail out early if the lengths aren't equal, but otherwise
yes, you'd want e.g. 1234 == 1345 to continue to the end even though it's
obvious from the second character that they aren't equal.

~~~
bmm6o
Bailing early reveals the information that the lengths are different. In most
cases the attacker knows the length of the target string and so this test will
never pass. You can probably imagine a scenario where the length isn't known
and step 1 is to determine the target length.

