Topic: Why use RFC6979 and is there any downsides? (Read 299 times)

Achow's post seems to sound like it's saying that there is some kind of danger in random K because of 'getting more information out' -- there isn't in and of itself,  to the extent that different K's "get more information out" so does signing multiple messages.

The reason for 6979 is that reliably generating random numbers is hard and it turns out that over and over and over again applications screw it up.  Worse, you can't easily tell when a random number is screwed up because it's random, one looks as good as any other. ... unless the screwup is so bad that they're just constantly repeating.  But basically any form of predictability of K will break the signature, even ones like being linearly related to the Ks in other signatures.

You still need to generate a secure random number to get your private keys, but you only need to be successful at that _once_.  RFC6979 is really just a way to safely reuse that ONE random number you successfully got (the private key) for all your further transactions... rather than needing a constant influx of new random values, each one a potential point where a software error could cause the loss of your keys.

The fact that the procedure also gives the same signature every time for the same key/message if you don't use the optional extra-data input to 6979 is a bonus that makes software testing a lot easier,  but it is not the source of the advantage of this approach itself.

This distinction is important because multiparty schnorr (or mpc-ecdsa) signing can use RFC6979 but MUST be constructed in a way where the same signature is not repeated even for the same message.

When you sign the same message twice, you will get exactly the same signature. This reduces the risk of being vulnerable to attacks that involve multiple k values. Because you are producing the same signature, no new information is being created which reduces the possibility that your private key can be recovered. With non-deterministic signatures (i.e. random k), a new signature on the same message will have a different k and a different signature. So there is a possibility that there is some relationship between the signatures that can be found and exploited to find the private key. However there is no such known attack and it is safe to use randomly generated k's.

Using a deterministic nonce generation algorithm that takes into account the private key and message being signed such as RFC 6979 will allow for avoidance of the reused k attacks. Reusing a nonce in the signatures of multiple different messages signed by the same key will result in the private key being found. A deterministic nonce algo avoids this because including the hash of the message in the nonce makes it such that the nonce will always change for every message.

Electrum, Bitcoin Core, Armory (I think), and probably many many more. Most wallet software use RFC 6979.

I managed to find an old post with the same subject, here take a look.

Source: https://bitcointalksearch.org/topic/deterministic-usage-of-dsa-and-ecdsa-digital-signature-algorithms-rfc-6979-285142

I can not understand why RFC6979 is used for generating k while creating a signature.


So basically k is the same as a private key. So why not use the same process for creating a truly random private key here also? Why make it "deterministic " and most importantly what are the pros and cons of doing this?

Also which implementations are doing this?
I can already confirm that Electrum is using RFC6979 ref since it is easier to go through python for me and also I didn't have time to check all of them yet...