Can we decide on RFC 6979 or an equilvalent before we have more issues?

[CIYAM]

We have seen a big problem with compromised private keys due to bad random values used by crappy .js code (and this is not the first time we have seen such things) yet the Bitcoin devs seem to not be very enthused about changing things (presumably they are very busy with other things but I am asking them to consider what is most important at the moment).

I think this needs to be elevated to priority #1 as if people can't trust their private keys due to poor RNG (and we have been made aware that the NSA seems quite determined to compromise RNGs as much as they can) then we can't really trust anything to keep BTC safe.

We need deterministic sigs and we need them ASAP - if there is an issue with RFC 6979 then please solve it via another RFC or create a BIP that achieves the same thing.

The main thing is - stop with not doing anything and let's get deterministic sigs happening so no further such issues as have happened recently with blockchain.info happen again.

[hhanh00]

Huh ... many wallets already have this RFC implemented: nbitcoin, bitcoinj, libbitcoin, bitcoinjs.
The notable exception is bitcoin core but it's just a matter of time. It's in the dev branch and the next release will have it. (https://github.com/bitcoin/bitcoin/pull/5227)

Unfortunately, you cannot check if it was used because you would need to know the private key.

IMHO, we shouldn't use ECDSA at all but I may be missing the big picture. Anyway, until then - no hardware wallets for me. I can't check that the software installed isn't doing anything harmful.

[CIYAM]

Huh ... many wallets already have this RFC implemented: nbitcoin, bitcoinj, libbitcoin, bitcoinjs.

Interesting - as the feedback I'd got from gmaxwell was that he didn't think that the RFC should be used.

IMHO, we shouldn't use ECDSA at all but I may be missing the big picture. Anyway, until then - no hardware wallets for me. I can't check that the software installed isn't doing anything harmful.

If not ECDSA then what (RSA)?

[548845]

We have seen a big problem with compromised private keys due to bad random values used by crappy .js code (and this is not the first time we have seen such things) yet the Bitcoin devs seem to not be very enthused about changing things (presumably they are very busy with other things but I am asking them to consider what is most important at the moment).

I think this needs to be elevated to priority #1 as if people can't trust their private keys due to poor RNG (and we have been made aware that the NSA seems quite determined to compromise RNGs as much as they can) then we can't really trust anything to keep BTC safe.

We need deterministic sigs and we need them ASAP - if there is an issue with RFC 6979 then please solve it via another RFC or create a BIP that achieves the same thing.

The main thing is - stop with not doing anything and let's get deterministic sigs happening so no further such issues as have happened recently with blockchain.info happen again.

It is NOT their code that is crappy.
Though I agree there is a problem.

Are you sure deterministic sigs will solve the problem though?

[CIYAM]

It is NOT their code that is crappy.

It certainly was their code that was crappy - it lacked initialisation that led to the cracking of private keys (maybe you need to read up more on what happened).

Are you sure deterministic sigs will solve the problem though?

For sure deterministic sigs will get rid of the problems of poor random values (but of course that won't get rid of all problems).

[548845]

It is NOT their code that is crappy.

It certainly was their code that was crappy - it lacked initialisation that led to the cracking of private keys (maybe you need to read up more on what happened).

Are you sure deterministic sigs will solve the problem though?

For sure deterministic sigs will get rid of the problems of poor random values (but of course that won't get rid of all problems).

Sorry, I was following your discussion with gmaxwell on the same subject but different thread but failed to see that.
Got a link?

When did this happen btw?

[hhanh00]

If not ECDSA then what (RSA)?

DSA has the same problem. I don't know what would work well. Subliminal free signatures introduce other issues or are impractical IMO. But smart people are working hard in this field...

[CIYAM]

It's funny - but as soon as I learned that ECDSA (at least in terms of what is used by Bitcoin) relied upon random values I saw a weakness.

So although not happy about it I am not surprised that we have ended up with this situation (I've never liked the idea of relying upon random numbers).

[548845]

So can I have a link for what happened exactly.

All I heard was that some keys were compromised.

Can I know more please?

[548845]

I asked if you have a link.

I don't have a link but why not just search about "R values" - as that is the topic that you'll find (it should be about the first thing you find).

Thank you Ian - I truly mean this.

 

[CIYAM]

Fighting is rather pointless - let's just try and help each other with useful information.

This is the link you are interested in: https://bitcointalk.org/index.php?topic=581411.0

[548845]

Fighting is rather pointless - let's just try and help each other with useful information.

I am all in for that, but on the specific subject I believe I have more to learn.
In fact I have a lot to learn on the specific subject.

But I do recall someone saying that deterministic sigs will bring up other issues.
I don't remember what those issues are but I remember it sounded somewhat serious.

[CIYAM]

I don't remember what those issues are but I remember it sounded somewhat serious.

Unfortunately all sig methods are problematic (whether deterministic or not) and some smart people have shown ways that you can have corrupt software disclose your private keys without you even knowing.

I don't think we have any current way to be safe from that.

[LeMiner]

I don't remember what those issues are but I remember it sounded somewhat serious.

Unfortunately all sig methods are problematic (whether deterministic or not) and some smart people have shown ways that you can have corrupt software disclose your private keys without you even knowing.

I don't think we have any current way to be safe from that.

If no one would ever reuse addresses there wouldn't be a problem, which is what everyone should be doing already anyway?

Somewhere in the future we will have to step over to quantum proof signature schemes like CMSS40 or GMSS40 anyway. The problem with these currently is that they would take too long to generate and would take too much space.

[hhanh00]

These quantum signature schemes don't help solving the problem. A malicious implementation can reuse the same branch multiple times and effectively reveal your secret key.

[cyberpinoy]

We have seen a big problem with compromised private keys due to bad random values used by crappy .js code (and this is not the first time we have seen such things) yet the Bitcoin devs seem to not be very enthused about changing things (presumably they are very busy with other things but I am asking them to consider what is most important at the moment).

I think this needs to be elevated to priority #1 as if people can't trust their private keys due to poor RNG (and we have been made aware that the NSA seems quite determined to compromise RNGs as much as they can) then we can't really trust anything to keep BTC safe.

We need deterministic sigs and we need them ASAP - if there is an issue with RFC 6979 then please solve it via another RFC or create a BIP that achieves the same thing.

The main thing is - stop with not doing anything and let's get deterministic sigs happening so no further such issues as have happened recently with blockchain.info happen again.

I am not sure what it is the devs are busy doing, but this coin is certainly not at the top of thier priority list in any way, that you cna be sure of. I think they get up everymorning, sell 200 bitcoins each and just watch the newsfeeds about bitcoin, then go play golf. They are waiting for us (the community) to do all the work for them.

[Alan Turing]

We have seen a big problem with compromised private keys due to bad random values used by crappy .js code (and this is not the first time we have seen such things) yet the Bitcoin devs seem to not be very enthused about changing things (presumably they are very busy with other things but I am asking them to consider what is most important at the moment).

The issue you are talking about (random nonces being found to be not that random) is not a Bitcoin problem, rather third parties (Counterparty and Blockchain.info) making cryptographic errors in their applications. Bitcoin Core has never had a problem with the security of it's ECDSA signatures.

We need deterministic sigs and we need them ASAP - if there is an issue with RFC 6979 then please solve it via another RFC or create a BIP that achieves the same thing.

Deterministic signatures is a low priority in Bitcoin Core because the random number generator it uses is cryptographically secure. If it wasn't RFC6979 wouldn't make any difference because the private keys are made by the same function and therefor weak as well. RFC6979 has a bigger impact on embedded devices such as the Trezor which don't have much of an ability to gather proper entropy on their own.

Interesting - as the feedback I'd got from gmaxwell was that he didn't think that the RFC should be used.

There's nothing undesirable about RFC6979 as such, it's more that it doesn't do what people expect. You can as a signer independently verify that your signature was correctly created using RFC6979, but somebody without the private key can not. Therefor it doesn't solve any problems regarding signers being able to roll their EC nonce and make a new, unique transaction.

We need deterministic sigs and we need them ASAP - if there is an issue with RFC 6979 then please solve it via another RFC or create a BIP that achieves the same thing.

Though utterly unnecessary, Bitcoin Core has had RFC6979 signatures in master since the 26th of October.

[CIYAM]

Though utterly unnecessary, Bitcoin Core has had RFC6979 signatures in master since the 26th of October.

Was not aware of that - thanks for the link.

[johoe]

I think we don't have to decide on RFC6979 altogether.  Every client can decide to use it for itself.

If the bitcoinj had implemented this last year (well this is impossible, since the standard is from August 2013), the Android random number generator bug would have had no bad effect.  OTOH, we probably would not have found the problems with openssl, randomness, and fork.

I heard that the counterwallet bug was not a weak randomness problem but a buggy implementation of deterministic k values. I don't know the details here.

For blockchain.info the impact would have been much smaller, but there would still have been the problem with weak addresses that were freshly created.  They implemented deterministic K values now.

[CIYAM]

I think we don't have to decide on RFC6979 altogether.  Every client can decide to use it for itself.

Sure - but any clients that continue to rely upon random numbers for sigs are going to be future targets for thefts (as there is simply no way that the client can guarantee the random number generator it is relying upon isn't rigged).

Perhaps what is best is that the "safety rating" of any particular wallet takes this into account (most end users are not going to understand the tech but they can understand a "poor safety" rating or the like).