But shouldn't we all be 100% RFC 6979 compliant if possible?
Here's some of the repos I cleaned up.
https://github.com/bitpay/bitcore/pull/884
Quote
I added a similar badrs function to python-ecdsa and compared the results.
The 1 badrs (aka forcing it to loop once) gave me a different value. It turns out you missed one of the v = hmac_k(v) steps during the loop.
Adding one extra v = hmac_k(v) in each loop makes it match up with python-ecdsa perfectly (I even tried up to badrs = 30 and it was fine.
https://tools.ietf.org/html/rfc6979#section-3.2
If you follow Step h from after the k = bits2int(T) downward, then back up to the beginning of Step h to loop.
As you can see, the original code in Bitcore was missing one V = HMAC_K(V) whereas python-ecdsa includes it in the loop.
Including this commit will make the behavior be 100% rfc 6979 compliant.
The 1 badrs (aka forcing it to loop once) gave me a different value. It turns out you missed one of the v = hmac_k(v) steps during the loop.
Adding one extra v = hmac_k(v) in each loop makes it match up with python-ecdsa perfectly (I even tried up to badrs = 30 and it was fine.
https://tools.ietf.org/html/rfc6979#section-3.2
If you follow Step h from after the k = bits2int(T) downward, then back up to the beginning of Step h to loop.
Code:
K = HMAC_K(V || 0x00)
V = HMAC_K(V)
Empty T
V = HMAC_K(V)
T = V (since we know tlen == qlen)
k = bits2int(T)
Including this commit will make the behavior be 100% rfc 6979 compliant.
https://github.com/blockchain/My-Wallet/pull/115
Quote
RFC specifies that if the k value is out of bounds OR if r or s is 0 you must loop through Step h until a proper value is found.
The way bitcore implements this is by including an integer called "badrs" that will force entering the re-hashing loop of Step h. The incrementing of badrs is done in a do while loop around k generation and r and s calculation.
The way bitcore implements this is by including an integer called "badrs" that will force entering the re-hashing loop of Step h. The incrementing of badrs is done in a do while loop around k generation and r and s calculation.
Quote
The only way this could be a security issue is if someone had a transaction + privkey pair that just happened to produce an out of bounds k (or in bitcore's case, a bad r or s)... AND they decided to sign that transaction using both bitcore/blockchain.info AND Electrum (uses python-ecdsa) and then for some reason posted those two signed transactions in the public space somehow.
Edit: Just put in PR to bitcoinjs-lib:
https://github.com/bitcoinjs/bitcoinjs-lib/pull/336