Sane implementations of Bitcoin cryptography routines w.r.t. side-channel attacks

Question

Bitcoin uses SHA-256, Base58Check, ECDSA (Sep256k1) and RIPEMD-160 as the basis of its encryption (see this article for a short guide on how addresses are created).

I would like to create an iOS-based wallet app that offers reasonable security.

• OpenSSL is not available on iOS, and is quite a large dependency. What I'm looking for are specialized libraries that mainly focus on the Bitcoin algorithms. The OpenSSL code also is very hard to understand, making me wonder if there is really no better way.

  • libbitcoin and the official Bitcoin-Qt client both use OpenSSL.
  • OpenSSL generally has a mixed reception.
  • OpenSSL also added to the transaction malleability problem that recently made its round in the news, as OpenSSL has more relaxed criteria to accept a signature than strictly necessary.

• bitcoinj uses Spongy Castle, also a large collection of algorithms.

• Another option of an algorithm collection is Crypto++ which I haven't seen in existing Bitcoin clients so far.

• Apple's Security framework only supports RSA on iOS.

• Chromium includes Go-sources for ECDSA.

• There is sipa's implementation for Sep256k1 that has a reputation of being very efficient. It is also listed under gh/bitcoin.

Many recent attacks in publications used side-channel attacks, making it necessary to have algorithms with constant-time execution (to avoid timing-related attacks) and additional protections against cache-based attacks and recently even audio-related attacks where noise that the hardware itself produces can be used to gain knowledge of the private key.

Even though many attacks require gathering of multiple signatures, one cannot know how the app will be used by the end-user. I do not want to rely on the assumption that the users doing transactions only a few times per day in different shops and exchange their Bitcoin addresses frequently.

My questions are:

• Is there a "sane" implementation of the algorithms used by bitcoin? e.g. are there high-quality implementations available that incorporate defenses against side channel attacks?

• Does OpenSSL already protects against side-channel attacks?

  • A mobile app is more open to side-channel attacks than the desktop PC standing at home, so what's reasonably secure on a desktop machine may not be secure enough for a mobile app.
  • As OpenSSL is probably the most used cryptographic library, it's probably also the most attacked one, and therefore, ahead when looking at general security. However, specialized libraries may have a higher quality for the few algorithms they implement, as the code base is much smaller and easier to understand.

• How can I train myself to evaluate whether an existing implementation is vulnerable to certain types of attacks?

  • Cryptographic algorithm implementations are often only poorly documented and optimized to a point where the code consists of magic numbers chained together with arbitrarily seeming operators.
  • One aspect I already mentioned is the concept of constant execution time, which counters timing-related attacks.

• Are there good resources that explain how to implement those algorithms myself? I do not intend to use my own implementation for the app, but I am interested in understanding how the stuff works I'm using. Entry-bar seems quite high. Can the "Guide to Elliptic Curve Cryptography" book be recommended?

PS: I know that Apple doesn't favorably treat Bitcoin-related apps in their store. However, this discussion is out of scope of this question.

PS2: Base58Check is only used as a special encoding to make Bitcoin addresses and keys more readable to the enduser. There is no cryptography involved there, and it's easy to implement - I only included it here for completeness.

Answer 1

Is there a "sane" implementation of the algorithms used by bitcoin? e.g. are there high-quality implementations available that incorporate defenses against side channel attacks?

libsecp256k1

Does OpenSSL already protects against side-channel attacks?

haha^*

How can I train myself to evaluate whether an existing implementation is vulnerable to certain types of attacks?

• Review the claims. If it doesn't even claim side channel resistance, worry.
• Review the track record. If it's been subjected to side channel attacks repeatedly and it doesn't claim to have taken a serious comprehensive approach to fixing them, worry.
• Identify the physical observables of interest. If you're talking over the internet, you probably don't need to worry about power analysis. But if you're making a smart card that a hapless luser will put into a malicious ATM, you may need to worry about it.
• For timing side channels:
  1. Identify a set of primitive computations that you take as constant-time. Typical set: copying data, $w$-bit addition and subtraction, bitwise operations, constant shifts and rotates. Multiplication can be questionable.
  2. Follow the data flow of secrets. If you can find any primitive computations that depend on the values of secrets, like the conditions of branches or the addresses of memory references, *bzzzzzrt*. If you can prove they flow only into the safe operations, you might be OK.
• Try not to handle individual bits at a time, and keep up with the state of the art because technology moves fast.
• Pay attention to tools like gfverif.

Are there good resources that explain how to implement those algorithms myself? I do not intend to use my own implementation for the app, but I am interested in understanding how the stuff works I'm using. Entry-bar seems quite high. Can the "Guide to Elliptic Curve Cryptography" book be recommended?

Our friendly neighborhood bear has some good references. Reading existing implementations is indispensible, and the abysmal code quality of a lot of otherwise good cryptographers can provide good motivation to get into implementation yourself. For references on elliptic curve cryptography, we have lots on this site!

---

_{^* In fairness to the modern OpenSSL team, they inherited a gigantic legacy code base and they are doing their best to clean it up and plug side channels without severely damaging performance. Unfortunately, these goals—maintain legacy code base, preserve performance of bad cryptosystems—often come into conflict with side channel security.}