
Robust and Efficient Elimination of Cache and Timing Side Channels - luu
http://arxiv.org/abs/1506.00189
======
julie1
Since wait/sleep are not CPU intensive does not it open the door for a "power
consumption" attack? Plus, using interruption/clock is not very stealth: it
implies switching context, sending signal to a clock, and waiting for a
specific interrupt to wake you up (plus reloading context ....).

I guess as usual that during heavy load it may backfire on some hardware by
changing its behaviour when there is a pressure to access the clock enabling a
potential DOS (on some hardware like heavily asynchronuous equipment like
routers for instance, I totally can feel the CPU overload while there is
almost no process, IO that requires close to RT beginning to fail
unexpectedly, clock drift...).

I mean you don't need a PhD to anticipate this.

It seems a totally elegant, simple and wrong solution to me.

~~~
loser777
Power consumption is assumed to not be part of their threat model.

>Similarly, we assume that the attacker

>does not have physical access to the hardware and cannot

>monitor side channels such as electromagnetic radiations,

>power use, or acoustic emanations.

------
themeek
Wow, this is incredible. Great work and an out-of-the-box and obvious-in-
hindsight solution.

The performance numbers are inspiring.

Will be interesting to see crypt-analysis that attempts to break a solution
like this.

~~~
tptacek
There are so many moving parts, and so much of this pertains to the
microarchitecture (which isn't really documented), that it seems inevitable.
It's very cool; I'm not sure how practical it is.

------
earlz
I never really understood why just placing the equivalent of
`wait(GetRandom())` isn't an efficient way to block timing attacks

~~~
resc1440
One reason is that in many cases, it's easy to do a large number of trials, so
this only makes an attack slightly less practical. They go from being able to
tell your secret after 10 packets to needing 100 or 1000.

~~~
throwawait
Yep. After many trials you're just left with the addition of the average value
of whatever random distribution you're pulling delays from.

