Based on the time-frame and my impression of the capabilities of the various groups developing wallet software during that period my initial guess was that the Bitpay copay software might be the source of these signatures. Copay is a multi-signature wallet which was initially released around that time.

As I’m not a javascript developer it took me a bit of effort to dig trough the historical dependencies to find the code that was applicable at that time, but I believe my suspicion is likely confirmed:

[If there exists some tool to go grab all of the dependencies of a JS application as of some date that would have been super useful.]

return new bignum(SecureRandom.getRandomBuffer(8));

This code chooses an 8-byte (64-bit) nonce. I’m unclear as to how exactly this mistake came about– sending 32 to a function that took bits as a size argument, for example, would have made sense–, but however it happened it wasn’t caught in review and appears to have been shipped.

The pull-request that introduced the vulnerability was making the javascript cryptography implementation faster by switching the underlying EC operations to a different library, ‘elliptic’. At the time elliptic featured its own signing functions which included RFC6979 deterministic nonce generation. I don’t see why the code wasn’t changed to use this signing function even with the author of elliptic commenting in support of the PR but since there was pre-existing ‘home rolled’ signing code it just may not have occurred to anyone to switch to the library routines. There isn’t a lot of discussion on the pull-request.

The vulnerability was subsequently fixed but weak signatures continued being created for some time. Because Bitpay’s bitcore was promoted as an all purpose Bitcoin library it’s possible that other software than copay had adopted it.

I’m unable to find any announcement of the vulnerability other than the fix in the repository.

Though I haven’t carefully analyzed it, I noticed that prior to switching out the code that codebase previously used “bitcoin-js” which– at least in some versions– used a weak random number generator due to a review evading subtle type error so it may well be the case that the error introducing change simply changed the software from one form of weakness to another.

It’s also possible that although this software had exactly the right vulnerability introduced at the right time that it was coincidental and the bad signatures found in the paper were created by some other implementation.

I think the research and the relevant code make for a fine example of how difficult it is to get these things wrong, how even small errors can result in total security breaks, and that the mere fact that something is open source does not automatically ensure that it has received adequate review.

Article First Published here