Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
Ok. I was seeing it as insurance against faulty PRNGs. Hardware wallets are always going to have a problem in ensuring the private keys are generated ok anyway.
But if you did want to check the signing nonce would it be possible to pre-generate a file of random numbers, store them on the wallet and give them to the purchaser of the wallet in a file or online, then deterministically generate the number and add the next number from the random number file and reduce mod n and sign with this?
But if you did want to check the signing nonce would it be possible to pre-generate a file of random numbers, store them on the wallet and give them to the purchaser of the wallet in a file or online, then deterministically generate the number and add the next number from the random number file and reduce mod n and sign with this?
Sure, I suppose you could do this. However, its probably easier to do the following if your wallet is conforming to BIP 32 and using RFC 6979 for signing:
1. User generates their own master seed
2. User, with software running on their own computer, generates N keys using BIP 32 and the seed from step 1 and signs a bunch of test transactions using these keys.
3. User loads your HW wallet with the master seed from step 1
4. User asks your wallet to sign the same test transactions they did in step 2.
5. User compares his local signatures with the ones generated by you, if they match - your wallet is working as expected without any code review needed.
Now, the normal user will generate a master seed based on input from the user plus randomness from your device. This seed is displayed only on your devices screen so it never leaves the device. The user could then, if they so chose, repeat steps 2,4,5 on a secure computer to again verify your wallet was 100% doing as they expected.
This is what I plan on doing for my device. I think its pretty solid. And I don't buy the argument that you need 'insurance' by adding randomness to RFC 6979 - if you think you need to do that aren't you saying you don't trust that SHA-256 is truly a 1-way trapdoor function with no fast way to brute force it? If you believe that then there are alot more problems in the Bitcoin protocol itself which relies on SHA-2 for alot of things.
I'm happy to be proven wrong if anyone finds something bad about my logic above
