> Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet?
This particular attack is not really about ECC, and more about the processor & program you use. One "easy" way to immunize yourself against power analysis is to have your implementation be "constant power". That is, no information must flow from secrets to power.
The first step is coming up with hardware with constant-power operations. Then the cryptographic engineer must make sure the power-variable instruction never have secret inputs. That may require compiler support, writing assembly code by hand, or formal analysis.
That can be wickedly hard indeed, but it also has little to do with ECC specifically. The deep knowledge required there is about hardware, compilation techniques, formal methods… The only ECC specific part is identifying the secrets, and that's comparatively trivial.
I want to point out just so people understand that NO popular platforms meet these criteria for any algorithm whatsoever. Any CPU with any form of branch prediction or speculative execution can't be made truly totally secure against these attacks, and that is all high performance CPUs.
I suspect these sorts of issues are why black box hardware units like NSA type I encryptors are used for the most sensitive communication.
What you can do with popular platforms is try to mitigate the most egregious and easily exploitable variants by (a) not branching on secret data and (b) avoiding lookup tables or other memory access patterns that depend on secrets. The latter much harder to achieve and is why AES sucks on chips without hardware AES support. (But on chips with that support, it becomes better than alternatives!)
There are other competing practical concerns though like power use, speed, and standards compliance.
This stuff is hard.
Edit: these sorts of attacks do matter and are worth trying to mitigate if your code will ever run in the cloud. In that case it will run on multi tenant machines where there may be malicious neighbors who can analyze timing on shared hardware.
This particular attack is not really about ECC, and more about the processor & program you use. One "easy" way to immunize yourself against power analysis is to have your implementation be "constant power". That is, no information must flow from secrets to power.
The first step is coming up with hardware with constant-power operations. Then the cryptographic engineer must make sure the power-variable instruction never have secret inputs. That may require compiler support, writing assembly code by hand, or formal analysis.
That can be wickedly hard indeed, but it also has little to do with ECC specifically. The deep knowledge required there is about hardware, compilation techniques, formal methods… The only ECC specific part is identifying the secrets, and that's comparatively trivial.