Bitcoin Forum
August 15, 2020, 05:58:42 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Why use RFC6979 and is there any downsides?  (Read 181 times)
Coding Enthusiast
Legendary
*
Offline Offline

Activity: 813
Merit: 1567


Bitcoin and C♯ Enthusiast


View Profile WWW
December 14, 2018, 12:06:49 PM
Merited by Foxpup (3), ETFbitcoin (1)
 #1

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

4.1.3 Signing Operation
1. Select an ephemeral elliptic curve key pair (k,R) with R = (xR, yR) associated with the elliptic curve domain parameters T established during the setup procedure using the key pair generation primitive specified in Section 3.2.1

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...

Projects List+Suggestion box
Donate: 1Q9s or bc1q
|
|
|
FinderOuter(0.4.1)Ann-git
Denovo(0.0.0)Ann-git
Bitcoin.Net(0.4.2)Ann-git
|
|
|
BitcoinTransactionTool(0.11.0)Ann-git
WatchOnlyBitcoinWallet(3.2.1)Ann-git
SharpPusher(0.10.0)Ann-git
100% First Deposit Bonus Instant Withdrawals Best Odds 10+ Sports Since 2014 No KYC Asked Play Now
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Pmalek
Legendary
*
Offline Offline

Activity: 1400
Merit: 1364



View Profile
December 14, 2018, 04:39:20 PM
Merited by Foxpup (2), dbshck (2), theymos_away (2), aliashraf (1), Coding Enthusiast (1)
 #2

I managed to find an old post with the same subject, here take a look.
Quote
Why make ECDSA deterministic?
There are two major reasons to use a deterministic algorithm here.  In regular ECDSA, if two signatures are created (different messages) with the same k value, the private key can be calculated.  This means that ECDSA immediately fails if k is not chosen randomly.  The recent Android mishap led to such a problem.  Using deterministic ECDSA avoids this.

Secondly, it allows easy verification of ECDSA implementations, using fixed test vectors.  Regular ECDSA implementations cannot use signature test vectors, because the signatures are random by design.

Source: https://bitcointalk.org/index.php?topic=285142.0

achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 2226
Merit: 3416


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
December 14, 2018, 05:35:36 PM
Last edit: December 14, 2018, 11:55:44 PM by achow101
Merited by Foxpup (4), suchmoon (4), dbshck (4), Coding Enthusiast (2), theymos_away (2), ETFbitcoin (1)
 #3

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?
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.

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...
Electrum, Bitcoin Core, Armory (I think), and probably many many more. Most wallet software use RFC 6979.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3150
Merit: 4171



View Profile
December 14, 2018, 08:22:36 PM
Merited by Foxpup (6), dbshck (4), DarkStar_ (4), Coding Enthusiast (3), ETFbitcoin (1)
 #4

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. Smiley
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!