There is no global decision to be made here. RFC6979 has to be implemented by each implementation itself, and there is no way to externally check which one transaction is created accordingly and which one is not.
RSA is dead, it is slow and it will be even slower. RSA 2048 will not be secure any more soon (for Bitcoin, ten years are soon!). Longer key lenghs does not help. If you really want a long-time secure RSA, you would need 15kbit keys, which is beyond serious consideration.
And even if it would work: RSA is only deterministic in principle. The mathematical basics of RSA are deterministic, but it does have a lot of flaws as well. To get rid of the flaws, you need to implement a lot of tricks including non-deterministic padding for messages. Serious implementations of RSA are not deterministic either.
Topic: Can we decide on RFC 6979 or an equilvalent before we have more issues? (Read 2885 times)
December 23, 2014, 10:11:52 AM
December 21, 2014, 09:22:29 PM
But I was wrong, they actually provide a way to check that the firmware isn't tampered - even if it is by them.
Tampered firmware can just feed you a copy of the correct firmware. 
(sane oil certification even gets the clueful folks, I guess).(Besides, the easiest is to avoid reusing any address)
(I don't use any hardware wallet)
December 21, 2014, 03:13:40 PM
But I was wrong, they actually provide a way to check that the firmware isn't tampered - even if it is by them.
Tampered firmware can just feed you a copy of the correct firmware. (snake oil certification even gets the clueful folks, I guess).The btcchip stuff apparently works with multisig... though it's a little odd to use because it doesn't have a display (it does a very clever thing where it acts as a USB HID device and you plug into another device to act as the screen.)
December 20, 2014, 10:19:46 PM
Picking a signature scheme based primarily on your ability to suppress side channels sounds like obsessive micro-optimization. While desirable, we have multisignature already, which is arguably better than sidechannel suppression, and doesn't excessively compromise the many far more concerning criteria.
Is there any hardware wallet that supports multisig? AFAIK Trezor doesn't yet. I was only concerned about subliminial channels because of the need to trust the wallet software. But I was wrong, they actually provide a way to check that the firmware isn't tampered - even if it is by them.
December 20, 2014, 03:52:50 PM
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...
Unique signatures are trivial and exist in many forms (e.g. the BLS signature scheme is automatically unique); They all have unacceptable tradeoffs: Huge increases in signature sizes, much less mature cryptographic assumptions, greatly increased verifier computational complexity, patents, one time use, lack of review, etc. (or usually a mixture of all these)Picking a signature scheme based primarily on your ability to suppress side channels sounds like obsessive micro-optimization. While desirable, we have multisignature already, which is arguably better than sidechannel suppression, and doesn't excessively compromise the many far more concerning criteria.
December 20, 2014, 03:48:24 PM
Interesting - as the feedback I'd got from gmaxwell was that he didn't think that the RFC should be used.
Huh??! No, I believe I was the first person to promote it in this community.Perhaps there was confusion over this point: It doesn't actually solve the problems you're talking about. The very same incidences caused the private keys to be just as insecure.
This doesn't mean that a strong derandomized DSA isn't a good idea, but it does less than many credit it for.
December 20, 2014, 05:51:19 AM
Ah, you are right. R would be entirely known. Should have had my coffee this morning..
December 20, 2014, 05:40:30 AM
If you did that, anyone can compute k and the secret key.
December 20, 2014, 05:36:33 AM
Since RFC6979 essentially states you seed a HMACDBRG with a private key and the message hash, purely to obtain a k value which is unique for this private key, is there any reason you cannot use the public keys x coordinate instead if the private key?
A 'problem' with the RFC is no one can tell if you were using deterministic signatures without your private key. Why assume its the private key? The public key is recoverable from a signature, so observers can verify you are carrying this out this procedure without your private key.
All that matters is they are unique.
A 'problem' with the RFC is no one can tell if you were using deterministic signatures without your private key. Why assume its the private key? The public key is recoverable from a signature, so observers can verify you are carrying this out this procedure without your private key.
All that matters is they are unique.
December 20, 2014, 05:31:48 AM
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).
December 20, 2014, 05:17:37 AM
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.
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.
December 19, 2014, 10:53:32 PM
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.
December 19, 2014, 10:44:18 PM
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.
December 19, 2014, 10:08:01 PM
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 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.
December 19, 2014, 09:36:34 PM
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.
December 19, 2014, 03:05:40 PM
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.
December 19, 2014, 02:22:08 PM
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.
December 19, 2014, 02:19:09 PM
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.
December 19, 2014, 02:17:10 PM
Fighting is rather pointless - let's just try and help each other with useful information.
This is the link you are interested in: https://bitcointalksearch.org/topic/reused-r-values-again-581411
This is the link you are interested in: https://bitcointalksearch.org/topic/reused-r-values-again-581411
December 19, 2014, 02:05:58 PM
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.
Jump to: