Quote from: klokan on June 11, 2014, 11:12:38 AM

Quote from: molecular on June 11, 2014, 07:34:35 AM

Quote from: klokan on June 10, 2014, 10:51:39 PM

Quote from: klokan on June 10, 2014, 10:34:43 PM

The answer to your question is NO. There is no simple way to chech this. There is a difficult way to test that in your particular test scenario RFC6979 is used.

One more comment: If I understand this correctly, the Trezor use case for signing transaction never reuses adresses. If k=1 was used all the time, only the private keys of the dead address will be revealed. There is still no known way to steal your BTC in this scenario. So the RFC6979 is good to have, but you are safe even without it.

Please correct me if I'm wrong.

I think you're wrong: the idea could be for the trezor devs to use k = in order to leak the seeds of people to the blockchain, visible only to them, of course.

It's a potential attack by the trezor devs, not just anyone.

There are million of ways how wallet devs (including trezor devs) can leak your seed. Some quick ideas:

thanks for your answer.

let me comment on the items in your list while thinking of RFC6979 compliance testing (assuming it's possible and done by at least some):

Quote from: klokan on June 11, 2014, 11:12:38 AM

1. Use above when the amount is above 10BTC (you don't care about poor guys anyway).

RFC6979 non-compliance can be detected with any single transaction above 10 BTC (there are going to be many of these, because "change")

Quote from: klokan on June 11, 2014, 11:12:38 AM

2. Use only last 16bits of RFC6979 and xor this with seed. This way k is still deterministic, but easy to break.

RFC6979 compliance test will result in: FAIL (or am I wrong here? not sure)

Quote from: klokan on June 11, 2014, 11:12:38 AM

3. Leak the seed in 1000th transaction (or milionth...)
4. Leak the seed with some particular transaction. I.e. if the amount mod 97 is 32, leak the seed.
5. Leak the seed with the special, undocumented command in the interface.

even if they only leak the seed in a low percentage of transactions, there is risk of detection by RFC6979 compliance test. Once detected, shit hits fan and it's over for them. Risk too high for reward (at least compared to when using random k)

Quote from: klokan on June 11, 2014, 11:12:38 AM

6. Combine some of above or invent your own.

Since all of above are weak approaches, this one is also weak.

Quote from: klokan on June 11, 2014, 11:12:38 AM

In my opinion, the true random k is a better option than RFC6979, but some devs don't even know how to generate random numbers and they still write wallets to store your money....

In my opinion it's not. True random k cannot be checked for at all. It's easy to slowly leak the seed (bit by bit if need be, or completely in one go XORed with or encrypted to attacker secret) in the "random" numbers without anyone being able to prove it. (just noticed XOR would be a bad idea since it would enable "freeloaders")