Runtime of if

One other method not yet suggested, suited only for relatively long times (more than an individual if statement with an assignment), would be to set a timer before the if, and wait unti it expires afterward. You'd tune the timer value for the amount of delay desired. Both paths would have the same delay; the shorter one just waits longer. You'd probably want to tune the timer value to the time of the longer path so that there's zero additional delay in that case.

As the complexity of the processors increases...

Worse yet, as the complexity of processors increases, the compilers and even programmers start to lose the ability to control execution time that precisely. For instance, there's "speculative execution", where the superscalar processors execute both paths of the if at the same time, and discard the useless path when they finally figure out the value of the condition tested. Branch prediction gives a preference to one path or the other, but that can sometimes change as code executes. When you have something like a modern Intel processor that's not even really executing the x86 assembly you feed into it, but instead has a lot of internal hardware that interprets that program in terms of other operations, it's hard to predict exactly what's going to happen and when.

Wasn't there a hack that could crack SSL keys based on differential timing of the responses? As I recall, it was something along the lines of incorrect digits in the key returning a response more quickly. They were able to detect right/wrong digits, and guess the key digit by digit instead of key-by-key. Sort of like in the movies where the crooks listen for the click of a bcombination lock. At any rate, there are some high-level reasons to have identical timing through all paths through the code, as well as the more familiar low-level timing issues.

One other method not yet suggested, suited only for relatively long times (more than an individual if statement with an assignment), would be to set a timer before the if, and wait unti it expires afterward. You'd tune the timer value for the amount of delay desired. Both paths would have the same delay; the shorter one just waits longer. You'd probably want to tune the timer value to the time of the longer path so that there's zero additional delay in that case.

As the complexity of the processors increases...

Worse yet, as the complexity of processors increases, the compilers and even programmers start to lose the ability to control execution time that precisely. For instance, there's "speculative execution", where the superscalar processors execute both paths of the if at the same time, and discard the useless path when they finally figure out the value of the condition tested. Branch prediction gives a preference to one path or the other, but that can sometimes change as code executes. When you have something like a modern Intel processor that's not even really executing the x86 assembly you feed into it, but instead has a lot of internal hardware that interprets that program in terms of other operations, it's hard to predict exactly what's going to happen and when.

Wasn't there a hack that could crack SSL keys based on differential timing of the responses? As I recall, it was something along the lines of incorrect digits in the key returning a response more quickly. They were able to detect right/wrong digits, and guess the key digit by digit instead of key-by-key. Sort of like in the movies where the crooks listen for the click of a bcombination lock. At any rate, there are some high-level reasons to have identical timing through all paths through the code, as well as the more familiar low-level timing issues.

Response time and current consumption has been used to attack the cryptography used in smartcards. So in some situations, it is better to have a random return time instead of trying a fixed time.