Quote from: natb on September 11, 2013, 02:06:23 AM

Quote from: Crowex on September 10, 2013, 09:32:15 AM

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?

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

I'm not making any arguments as to the security of SHA-256. To the question as to whether it was better to use deterministic RFC6976 signing nonces in preference to prng generated numbers I just suggested using both methods as a belt and braces option.
When you pointed out that my method didn't allow checking by a third party I gave an option that did and uses both methods so that if someone did have doubts about RFC6976 then they could be secure in knowing that there was a random element in the signing nonce.
I just thought it was an interesting idea to use pre-generated random numbers but I can't see a problem with it. Maybe there is?
As to generating private keys and BIP32, that's a completely different question.