ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels

I don't know that it's typical for research like this to comprehensively evaluate targets that aren't relevant to the research. Regardless, here we have an attack on the ECDSA k-nonce. People who use Curve25519 don't even use ECDSA; they use Ed25519's deterministic Schnorr-style signatures. It's not even the same signature construction.

So what you're asking of the authors seems a bit like the authors of the DROWN paper explaining that their RSA padding oracle attack doesn't work if you instead use DH key agreement.

Pieter did a cache timing attack project against DES at his university in 2004. I had experience with modeling fine scale algorithm delays as part of ultra-low latency audio codec work. So we had a little bit of additional background beyond regular systems programming and mathematical experience.

We spent time studying other implementations and academic papers on the subject-- just a product of searching and following citations-- and we implemented and measured (both in timing form and 'read the assembly' form). Pieter had to do some algebraic work to adapt a 'unified' group law approach to our curve and coordinate system. [Then all of this also presented additional verification work to validate that the new group law was algebraically correct.]

Because we accepted that this was going to be a considerable amount of work, we didn't refrain from trying multiple ideas and throwing things away. The libsecp256k1 codebase is written in a clean (IMO), typesafe, heavily tested way that makes iteration easier.

We initially implemented a bit-slicing approach to achieve memory access uniformity. After we thought we were at least a strict improvement over OpenSSL, we contacted an outside expert (Yuval Yarom, one of the authors of this paper, in fact) and they were kind enough to give our implementation a look-- and pointed out some additional research that showed our particular bit slicing approach was not quite constant time on common hardware. So we fixed that too.

I don't consider our work done on this-- we are likely vulnerable to differential power analysis on at least some hardware. We've implemented a basic level of blinding to harden against that-- but without a good measurement setup it's hard to tell if our efforts are helping (or maybe hurting, though that's unlikely). I loaned Thomas Daede a USRP, and he's been attempting to set up a DPA continuous integration rig for us (https://bitcointalk.org/index.php?topic=1319848.0); but it's effort that is competing with a lot of other projects for attention for all of us. Similarly some (now uncommon) hardware has things like data-variable time multipliers, and on that hardware little can be done beyond blinding; but again, without more analysis it's hard to know exactly where that stands.

Better silicon should solve some of these issues, for example adding some additional isolation between the power section and the logic a small super-cap with decent in-band filtering might do the trick.

As far as radiating EM goes I'm not sure what can be done but some more additional shielding and EM noise reduction should add some degree of protection.

Most implementations will eventually be vulnerable to some type of side channel attacks, the complexity and cost-vs-benefit is important here.

Launching an evil USB attack on the off chance of getting a key is most likely not very scalable, but considering that NFC/wireless payments for phones will become more and more common, and that crypto-currencies might actually end up being in common day use being able to extract keys during signing from EM leakage might just be the natural evolution of ATM/Payment Cards skimmer attacks.

In the past 2-3 years we had various key extraction attacks using "strange" vectors like EM/audio extraction, temperature, cpu usage, cross platform cache attacks, these attacks can threaten cloud computing and mobile computing quite severely unless we can root them out and being to modify the devices and platforms to be much more resistant to them.

Your assessment is correct. EdDSA is deterministic which eliminates the nonce-reuse concerns, but deterministic EdDSA/ECDSA requires side-channel resistance. I erred in my previous comment.