Timing Side-Channel Attacks

Might this be a hamfisted reaction to timing attacks?

the article links to side channel attacks and making it constant time. so hardly a valid accusation that it missed them.

Aren’t there already timing attacks based on cache latency?

These are timing attacks, if you can guarantee code runs deterministically, and deny access to timing information, you can defeat the attack.

https://en.wikipedia.org/wiki/Side-channel_attack#Countermea... might be of interest especially this part:"In the case of timing attacks against targets whose computation times are quantized into discrete clock cycle counts, an effective countermeasure against is to design the software to be isochronous, that is to run in an exactly constant amount of tim

Side channels are a huge danger. An example is cryptographic functions have been cracked because of timing differences based on the key or data being encrypted. This is why cryptographic ciphers are implemented in constant time code (i.e. code that always runs in the same amount of time regardless of its input).

I suppose timing attacks become an issue too.

I have the same feeling... https://en.wikipedia.org/wiki/Side-channel_attack#Countermea... mentions "isochronous" operations.

Is there any software-base implementation of AES that is NOT vulnerable to timing attacks and other side channel weakness and with reasonable performance (to the limit of the hardware)?

What about programming in the style used to avoid timing attacks. My understanding is that there are plenty of situations even today where for security purposes (side-channel timing attacks) you need your program to execute in a fixed number of steps independent of the input. Is this not enough to solve the problem?