[MarkMc]

I'm not an expert on timing attacks, but without clamping it seems quite tricky to guarantee that sensitive operations actually take constant time. There can be numerous subtle ways that timing information leaks while the code appears to be constant time. And programmers who touch sensitive code can easily forget the requirement for constant-time behaviour. Yes, having constant time operation without clamping is the best solution but it seems too easy to accidentally slip from this ideal.

I'm leaning toward the approach of having a simple clamping library at the application level that (a) throws an exception if the sensitive code takes longer than the 'clamp time'; and (b) has some simple heuristic to determine the clamp time, such as "double the maximum execution time recorded during the first 20 runs". It might have a drawback if the CPU is not idle, but the benefit is that it is dead simple to implement. (Assuming the platform supports nanosecond wait times)

[ircmaxell]

The far better approach is to just make the operations not depend on the secret.

You only really need to worry about timing attacks for values that the attacker doesn't know, and you don't want them to know.

So it's only things like encryption keys, passwords, session identifiers, reset tokens, etc that you need to worry about.

> And programmers who touch sensitive code can easily forget the requirement for constant-time behaviour.

And that's why I support the discussion we were having on PHP's internals list where we talked about making functions which are commonly used with secrets timing safe by default. As long as there isn't a non-trivial performance penalty to it at least.

As far as worrying about it, I'd rather people understand SQLi and XSS better. They are both FAR bigger surface areas than a timing attack ever will be. And likely going to be the bigger threat to 99.99% of applications.