|
My understanding is that the proposed
restrictions on the shader language already ban dependent texture
lookups, so that they should be able to block this particular
attack.
However, the opinion that I have already expressed here and on public-fx in the past, and that I still adhere to, is that even with only plain arithmetic operations and built-in math functions, and no branching or dependent texture lookups, it is already too dangerous to rely on the assumption that no timing attack exists. My reasons to believe that are: - On intel-compatible CPUs with x87 instructions, plain arithmetic instructions (add, mul) can take over 100x longer if some of the operands is non-finite. See http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0038.html . The objection to my argument was that just because this is the case with x87 instructions does not imply that it is the case with any current GPU. The point that I tried --- and failed --- to convey, is that this is too much detail to base the security of a Web standard on. - I hadn't started yet timing math functions such as sqrt/sin/tan etc, yet it is virtually impossible to implement them in a way that takes the same amount of time for all inputs. These functions are implemented in 2 phases: phase 1 takes an arbitrary number and reduce to the case where the number is in a given small segment; phase 2 implements the function as a polynomial approximation on this segment. It is phase 1 that is, for many math functions such as the trigonometric ones, very hard or impossible to implement with constant-run-time constraints. For logarithmic functions this is made relatively easy by the fact that the input number is already given in exponent form (mantissa * 2^exponent). For other functions this is hard and would come at the cost of a performance compromise. It's a bit optimistic to expect all GPU vendors to have already chosen such compromises to guarantee constant execution. If someone is interested in experimenting this, I would start with the sqrt and pow functions (try very large/small values), and continue with sin (try 2 things: very large values, and different locations in the [0;2pi] period interval). Benoit On 12-11-05 08:54 AM, Florian Bösch wrote: Based on this finding I wondered if restricting VS texture access + control flow restrictions would work. I do not think it would work. |