RSA and ECC have similarly-shaped common implementation strategies; just the underlying field arithmetic is different. You have a secret input (an exponent in RSA, or scalar in ECC) and work through it bit by bit, doing different operations if a bit is set vs not set (RSA: square and perhaps multiply, ECC: double and perhaps add). If the sequence of operations is visible to attacker (via power, time, cache, branch predictor, etc.) then your secret key does, too.
So, ECC implementations are not generally in a better state than RSA.
This is why curve25519 and its ilk are so much better; they can be efficiently implemented using the Montgomery ladder which is really very easy and cheap to make free of side-channels.
There are some architectural question marks. Will this device be shared among the VMs? If so timing might be a clue on what's happening inside. It is definitely not an easy problem to solve.
Considering multiple VMs share the same CPU, at times, I don't see it as a very convenient solution unless marketed as a "premium" package which very few will purchase given that these "attacks" are not that easy to carry out.
libgcrypt was written before timing side channels were an issue. modern crypto libraries (and OpenSSL) are at least supposed to be constant time and not to be affected.
11 comments
[ 137 ms ] story [ 426 ms ] threadI bet this would be much harder to do for ECC.
So, ECC implementations are not generally in a better state than RSA.
This is why curve25519 and its ilk are so much better; they can be efficiently implemented using the Montgomery ladder which is really very easy and cheap to make free of side-channels.
Unfortunately these attacks all focus on implementation issues rather than the underlying algorithms (hence the name).
[1] https://eprint.iacr.org/2014/140.pdf
http://pages.cs.wisc.edu/~rist/papers/cloudsec.html