This repository has been archived by the owner on Apr 20, 2022. It is now read-only.
Make RFC6979 compliant. #115
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
bitcoinjs-lib just merged their own implementation of this. It is slightly more elegant than the bitcore solution (what I am proposing here) but also is harder to see how it will work in action. |
|
Hard to do |
|
Looks like this is already dealt with. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have made the same pull request to bitcore in regards to the missing HMAC.
Please check here for an explanation for the extra
V = HMAC_K(V).bitpay/bitcore#884
As for the bad r or s:
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.
This is not a large issue, as the only possible vector of attack for it as is... is if someone had a transaction + privkey pair that just happened to produce an out of bounds k... AND they decided to sign that transaction using both blockchain.info AND Electrum (uses python-ecdsa, 100% RFC6979 compliant) and then for some reason posted those two signed transactions in the public space somehow.
Either way, this needs to be fixed.
I will make a pull request to bitcoinjs-lib later.