Bitcoin Forum
May 21, 2019, 05:54:00 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Why use RFC6979 and is there any downsides?  (Read 147 times)
Coding Enthusiast
Hero Member
*****
Offline Offline

Activity: 623
Merit: 849


Novice C♯ Coder


View Profile WWW
December 14, 2018, 12:06:49 PM
Merited by Foxpup (3)
 #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
Donation link using BIP21
Bech32 Donation link!
BitcoinTransactionTool (0.9.2):  Ann - Source Code
Watch Only Bitcoin Wallet (supporting SegWit) (3.1.0):  Ann - Source Code
SharpPusher (broadcast transactions) (0.10.0): Ann - Source Code

1558418040
Hero Member
*
Offline Offline

Posts: 1558418040

View Profile Personal Message (Offline)

Ignore
1558418040
Reply with quote  #2

1558418040
Report to moderator
1558418040
Hero Member
*
Offline Offline

Posts: 1558418040

View Profile Personal Message (Offline)

Ignore
1558418040
Reply with quote  #2

1558418040
Report to moderator
1558418040
Hero Member
*
Offline Offline

Posts: 1558418040

View Profile Personal Message (Offline)

Ignore
1558418040
Reply with quote  #2

1558418040
Report to moderator
BITDEER BTC/BCH ETH LTC ZEC DASH START MINING BTC NOW
WITH NEW GENERATION S17 ANTMINER!
Highly Reduced Electricity Fee $0.067/T/DAY! GET STARTED
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Pmalek
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1031



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

.FORTUNE.JACK.
      ▄▄███████▄▄
   ▄████▀▀ ▄ ██████▄
  ████ ▄▄███ ████████
 █████▌▐███▌ ▀▄ ▀█████
███████▄██▀▀▀▀▄████████
█████▀▄▄▄▄█████████████
████▄▄▄▄ █████████████
 ██████▌ ███▀████████
  ███████▄▀▄████████
   ▀█████▀▀███████▀
      ▀▀██████▀▀
         
         █
...FortuneJack.com                                             
...THE BIGGEST BITCOIN GAMBLING SITE
       ▄▄█████████▄▄
    ▄█████████████████▄
  ▄█████████████████████▄
 ▄██
█████████▀███████████▄
██████████▀   ▀██████████
█████████▀       ▀█████████
████████           ████████
████████▄   ▄ ▄   ▄████████
██████████▀   ▀██████████
 ▀██
█████████████████████▀
  ▀██
███████████████████▀
    ▀█████████████████▀
       ▀▀█████████▀▀
#JACKMATE
WIN 1 BTC
▄█████████████████████████▄
███████████████████████████
███████████████████████████
██████████▀█████▀██████████
███████▀░░▀░░░░░▀░░▀███████
██████▌░░░░░░░░░░░░░▐██████
██████░░░░██░░░██░░░░██████
█████▌░░░░▀▀░░░▀▀░░░░▐█████
██████▄░░▄▄▄░░░▄▄▄░░▄██████
████████▄▄███████▄▄████████

███████████████████████████
███████████████████████████
▀█████████████████████████▀
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1764
Merit: 2377


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), dbshck (4), suchmoon (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: 2730
Merit: 2253



View Profile
December 14, 2018, 08:22:36 PM
Merited by Foxpup (6), dbshck (4), DarkStar_ (4), Coding Enthusiast (3)
 #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!