
Timing Attacks Explained - r11t
http://emerose.com/timing-attacks-explained
======
joe_the_user
I'm not an encryption nerd but shouldn't it be possible to put some kind of
staggered delay on all your encrypted packets to keep this from happening?
Delay any encrypted packet that is leaving more quickly than average?

This could be inherently opaque whereas reworking the algorithm might result
in something else whose timing one could exploit. In fact, asking that the
algorithm both work correctly _and_ work at fixed rate seems like a separation
of concerns violation.

~~~
tptacek
I don't know why you're being downmodded for asking a reasonable question, but
the straightforward answer is that it's _much_ more difficult to mask the
timings of a naive comparison than it is to simply run a timing-independent
comparison function. Every simple answer you come up with to conceal timing
has a measurement counterattack.

It takes just a few lines of code to implement MAC comparison securely. Why
waste time and several more cycles of security problems and fixes?

~~~
joe_the_user
Just to play the devil's advocate. It takes a few lines of code if you are in
a language or system where you're controlling everything. If you're in a high
level language where you don't control how comparison is implemented, it could
get harder. Even more, comparison is only the start of conceivable timing
attacks. Suppose you could use decryption time or look-up time or whatever?
What would seem nice about operating on the packet level is that you could
stop potential future attacks.

------
DaemonXI
Aw, I thought timing attacks referred to StarCraft II rushes. I am so looking
forward to that game...

------
albemuth
I was thinking 4-gate timing attack, 7/27 can't come soon enough...

~~~
unavoidable
Yeah... not to sound all nerdy, but that was totally what I was expecting as
well. Oh the glorious strategies to be had with an all new game!

------
astrofinch
Noticing that vulnerability was massively clever, IMHO.

~~~
tptacek
It's clever in a number of ways, from the original absurdly clever notion of
"side channel attacks" Nate Lawson's old boss Paul Kocher pioneered in the
'90s, on through the notion of looking for the same mistake in HMAC
implementations (like the one Nate found in Google Keyczar), on through
starting a project to go look for timing vulnerabilities in common crypto
vulnerabilities.

Having said that: now that you know what an HMAC timing attack looks like, it
is extremely easy to go find new ones. Go to any source code search site,
search for "HMAC", and look how they compare signatures. Chances are, they use
the language's standard compare function, and they're likely vulnerable --- as
long as you can send candidate messages and get responses.

------
Kirvy
Doesn't an Intrusion Detection System stop such attacks? Assuming there is
one.

