[xenog]

The correctness of the implementation is not worrying me at this point. ECDSA is not too complex to implement. We have QuickCheck tests, and many others that make us confident that the code works well, or at least that it does what it intends.

I'm more worried about more sophisticated attacks, like timing attacks, for example. But I don't see how that can be used to attack this particular application.

[oakwhiz]

In my opinion, timing attacks are a major issue with cryptographic schemes written in Haskell. Perhaps there is some way to leverage the type system to create provably constant run times for particular chunks of code. I'm not sure how far this idea could be extended - perhaps it could even be implemented as a GHC extension, so that regions of compiled code contain cache timing attack mitigation.

Essentially, the problem here is that any decision based on secret information must act exactly the same regardless of the result, e.g. a secure string comparison should examine the entire string before concluding that the strings are different. Additionally, any decision based on another decision involving secret information must also follow the same rule - secret information contaminates regular information. So perhaps the solution is to give secret information its own type, incompatible with regular information, unless explicitly interacted with using a special interface.

[xenog]

This in an isightful comment. Lazy evaluation combined with the level of abstraction in Haskell could make this micromanagement somewhat hard to implement. It is in our roadmap to revisit the cryptography implementation.

[xenog]

Be careful when running the code in a way that can lead to an attacker finding a way to use a timing attack. Anywhere where signatures are done automatically could lead to potential problems. This is also true for Electrum, that implements its own crypto too, and browser-based clients.