

Remote Timing Attacks Are Practical - llambda
http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

======
gwern
Wow. Read 'datacenter' for 'machine in the local network'.

~~~
tptacek
Yes; more accurately, read "anywhere in EC2 to probably anywhere else in EC2".

------
tylerni7
Just so everyone knows, this specific attack is rather old. Modern versions of
the RSA algorithm use blinding to specifically prevent this, which causes the
RSA calculations to effectively be performed on random data.

There has also recently been a published timing attack regarding elliptic
curve signatures, and there are some older papers about AES's vulnerability to
timing attacks due to cache misses when using S-boxes. So while this paper
specifically isn't a viable attack today, it is still relevant.

------
indygreg2
This was published in 2003: <http://portal.acm.org/citation.cfm?id=1251354>

That doesn't change the importance of securing against timing side-channel
attacks, however.

~~~
tptacek
In fact, the attacks have gotten much better since then; for instance, see
Crosby & Wallach's paper on using statistical filters to establish nanosecond
timing bounds on "local" (ie, cross-datacenter) networks:

<http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf>

------
sillyhobbitses
In other words, don't use versions of OpenSSL that are almost a decade old.

~~~
patio11
It is a novel _class_ of attacks, and bites many people squarely on the
hindquarters. For example, every available Java OpenID implementation was
timable back in _2010_.

