Hacker News Reader

Comment by implr | Hacker News Reader

Awesome library, but I'm a bit worried that they chose to implement their own crypto(mostly ECDSA), instead of using an existing implementation known to be correct.

View on HN

I am one of the authors of Haskoin. We have had internal discussions on this topic. It was agreed that we wanted to minimize dependencies to code written in another programming language, which was the reason we did not choose one of the existing C++ crypto libraries, such as OpenSSL. My colleague Philippe, who wrote the crypto code, deemed the existing Haskell crypto libraries unsuitable. Hence we rolled our own ECDSA.

It's not really a problem, as long as you've got extensive test cases (perhaps with millions of randomly generated samples) to show that the implementation always has the exact same results as OpenSSL's.

Or even better, since ECDSA is used in bitcoin-qt, just show that the full bitcoin implementation has the same results as bitcoin-qt, with millions of samples.

I don't see any of that in your package though.

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.

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.

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.

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.

Reply on news.ycombinator.com