No. This is basic signal processing. Increase the noise, and all you do is increase the number of measurements needed to recover the signal.
This is a really common misconception about defeating timing attacks.
A more pernicious problem is that many of these microarch side channel attacks don't rely on direct timing of crypto code, so much as on microarch artifacts.
(For what it's worth, the specifics beyond this get to a place where I'm out of my depth and Colin and Nate are still in theirs.)
Right, I get that, increase the noise by a factor of two and you'd need more samples, increasing the chance of detection but ultimately not making the problem much harder.
But every factor of two that you make it harder is effectively one bit extra on the key that you're trying to find right ?
Assuming that's true (going out on a limb here) the more you are willing to waste time the harder it will get for an attacker to recover the keys, so ultimately it is a measure of efficiency vs security.
As for micro architecture, I don't know much about that other than reading up on the 68K when it came out and how it functioned at the block level, but one way to side-step that issue completely if you want to write bullet proof crypto code (if that is even possible) would be to write it for a controller on a separate plug in card (pci, possibly usb) that would be permitted to allow exactly one crypto operation per fixed interval of time to be performed.
That way you could effectively 'hide' the key and all its side-effects from view from both local and remote attackers.
It would then take at a minimum physical access to the card to monitor its buses in order to recover they keys.
This is a really common misconception about defeating timing attacks.
A more pernicious problem is that many of these microarch side channel attacks don't rely on direct timing of crypto code, so much as on microarch artifacts.
(For what it's worth, the specifics beyond this get to a place where I'm out of my depth and Colin and Nate are still in theirs.)