Move away from pybitcointools

[chris-belcher]

this is the third ECDSA impl with flagrant timing sidechannels i've seen in like 18 hours

belcher: fwiw, I believe that pybitcointools is a completely naieve implementation, written by a single person, which has never been peer review, which is internally undocumented and completely without tests, which was the authors first cryptographic code, by an author who'd previously written a number of completely broken wallet tools (e.g. reading the mouse position three times in a tight loop and adding math.random() to generate a private key)

ok, so it sounds like the project should be moving towards using python-bitcoinlib instead of pybitcointools

yes

[chris-belcher]

python-bitcoinlib doesnt seem to have BIP32 support, so pybitcointools will probably still be around for stuff like that.

[petertodd]

BIP32 support has been something I've been wanting as well...

Do you need pure Python or is the openssl call style good enough?

[chris-belcher]

What does "openssl call style" mean ?

[petertodd]

Whoops, sorry, that's really badly worded.

I mean how python-bitcoinlib currently uses the system OpenSSL libraries via ctypes, which requires users to have OpenSSL installed: https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/key.py

It also seems to be causing people problems on non-Linux platforms, which unfortunately I haven't been able to get fixes for yet: petertodd/python-bitcoinlib#30 (I don't have a Windows or Mac computer to test it on)

The fastest route to providing you with a solution - at least on Linux - would be to add BIP32 support to python-bitcoinlib using OpenSSL in the same way that Bitcoin Core itself implements it. That implementation I think we can trust not to have timing issues. Also, in general, I would argue that python-bitcoinlib is better tested and more reliable code than pybitcoinlib, but of course, I'm a bit biased there. :)

[chris-belcher]

To use python-bitcoinlib, users already need OpenSSL installed, so using it or pure python doesn't make much difference. The project already uses the external library libsodium for encryption so its okay asking users to install one more package.

You do not need to be fast. pybitcointools could work alongside python-bitcoinlib and slowly be phased out when ready. Right now it appears to be working fine. I will eventually move to python-bitcoinlib but at the moment you are probably more likely to lose your coins to a bug that labels them with the wrong value than to timing attacks.

[chris-belcher]

In light of this bug with pybitcointools, moving this project to python-bitcoinlib has moved up the todo list

vbuterin/pybitcointools#89

[petertodd]

Ah, yeah, I think that's due to the new low-S DER signatures stuff in Bitcoin Core. Version v0.4.0 of python-bitcoinlib does fix that problem: https://github.com/petertodd/python-bitcoinlib/blob/master/release-notes.md#v040

[chris-belcher]

I think it's time to start working on this. For a number of reasons including the malleability attack on the bitcoin network which involves lowS / highS in ECDSA. pybitcointools produces highS, the bitcoin core devs are hoping to reduce the amount of highS to very low levels and then soft fork to make it forbidden. Also the highS signatures make JoinMarket transactions stand out.

Also there's increasingly more serious money being involved so it seems wrong to have a non-cryptographer write the crypto.

[petertodd]

+1

[kristovatlas]

Given what a clusterfuck dependency on OpenSSL can be, I'm wondering if that can be substituted with a different library.