It is known that computing $a^x \bmod N$ takes $O(|x| + \mathrm{pop}(x))$ multiplications modulo $N$, where $|x|$ is the number of bits of $x$ and $\mathrm{pop}(x)$ is the number of $1$ bits (Hamming weight). This suggests a side channel attack by measuring the run time of the exponentiation.
Can the number of $1$ bits be derived from the run time, and can it somehow speed up finding of $x$ if $a$ and $N$ are known (assuming no countermeasures are used)?
Which countermeasures can be done?
Timing attacks against a function $f_k$ generally require two things:
Now, let's assume $f_k$ is the private key operation of Diffie-Hellman or RSA, that $k$ is the (fixed) private exponent of the target, and that the inputs are, say, 2048 bit integer values. Normally, the implementation of the operation $f_k(x) = x^k \mod p$ is such that it executes the exact same number of CPU instructions regardless of the value of $x$, so there will be no timing difference to observe (presuming the CPU performs e.g. a MUL or DIV at a fixed number of clock cycles).
There are however things to watch out for. If some $x$ is significantly smaller than the maximum size of 2048 bits and the implementation of modular multiplication is optimized to account for that, some of the least or most significant bits of $k$ might leak, depending on if the exponentiation implementation iterates the bits of the exponent from right to left or the other way around. Since the intermediate result grows exponentially, this will only reveal at most 11 bits of the exponent in the most unfavorable case of $x=2$.
To prevent this leak (again assuming the CPU performs a MUL instruction etc at a fixed number of cycles independently of the value of the operands), all that is needed to prevent such leaks is to justify the size of all inputs to the size of the modulus at the beginning of the exponentiation function implementation.
Now, next case, suppose the attacker is able to repeatedly slow down the system, at a time that averages out at the moment the target will either perform a modular multiplication because the corresponding bit of the private exponent $k$ is $1$, or not perform a modular multiplication because the bit is $0$. It suffices to say that if the modular exponentiation is e.g. performed by the CPU in a multi-threaded application, this can be done with some statistical accuracy, if the attacker somehow might control what else is executed by the CPU, either passively or actively.
One trivial way to blind the private key even in such cases, would be to always generate a fresh random integer $z$ that is invertible $\mod q$ where $q$ is a multiple of the order of $x$ (e.g. $p-1$ if the order is not known). Instead of calculating $f_k(x) = x^k \mod p$, you would calculate
The only step here that depends on the private exponent is the first, which has to be assumed to not vary in performance time depending on the value of $k$. The overhead of this method is on average a factor of 2, presuming modular inverses in $Z_q$ can be calculated in negligible time.
Another technique would be to make the number of modular multiplication completely independent of the bits of the private exponent, e.g. by using a sliding window technique. This means that a table of $2^m$ integers is built, and one of these values is picked for every $m$ bits of the binary representation of the private exponent. It should however be noted that this technique might make matters worse, e.g. if the time for picking one of the integers from the table depends on the index of that element.
It should also be noted, that while it has been advocated to blind the input value $x$ to-be-raised, instead of the private exponent, this will have no effect on a CPU that executes MUL independently of the value of the operand, and have no effect at all against both passive and active timing attacks that measure the timing differences relative to which bit position in the exponent is being processed.
Efficient constant-time exponentiation algorithms exist. For example, one could calculate a sequence as follows: Given $a^{k}, a^{k+1}$ calculate either $a^{2k+2}, a^{2k+1}$ or $a^{2k}, a^{2k+1}$. Both calculations differ only in which value is squared and which is multiplied, making them easy to implement with a single conditional swap as the only distinguishing feature. The choice of which to make starting with $1, a$ will depend on the high order bits of your exponent. These methods are used in elliptic-curve cryptography: look up the Montgomery ladder amongst others.
