Clarifications on RFC 6979

[Bronsted]

Hello all!

I have read the whitepaper and some of the more indepth aspects of Bitcoin. I have come across the implementation of RFC 6979. As far as I can tell, the motivation behind it is to eliminate the randomness of the PRNG being a weak link and resulting in the 'r' values being reused in subsequent signatures.

I have a few questions :

How does RFC 6979 ensure that the generation of the initial seed(?) to be random? Is this being implemented during the generation of the hierarchical deterministic seed to ensure randomness of the seed? To what extent is it effective if, lets say the source of the randomness is weak? Does Bitcoin Core use this, and if it does, can someone point me to the segment which this is implemented?

Thank you in advance.

[pooya87]

RFC6797 is about HTTP Strict Transport Security (HSTS) which doesn't seem to have anything to do with bitcoin.
RFC6979 is the closest thing to what you are talking about and is implemented by almost all bitcoin wallets and is used for deterministic generation of the ephemeral key (k) for usage in Elliptic Curve Digital Signature Algorithm (ECDSA) (it has nothing to do with seed). It is to eliminate any possible issues with the RNG by making signatures deterministic while still random.

[Bronsted]

RFC6797 is about HTTP Strict Transport Security (HSTS) which doesn't seem to have anything to do with bitcoin.
RFC6979 is the closest thing to what you are talking about and is implemented by almost all bitcoin wallets and is used for deterministic generation of the ephemeral key (k) for usage in Elliptic Curve Digital Signature Algorithm (ECDSA) (it has nothing to do with seed). It is to eliminate any possible issues with the RNG by making signatures deterministic while still random.

Thank you. I have amended the topic to reflect the error. Can you help me clarify some of my doubts as stated in the post? I still don't understand how it could be deterministic yet random at the same time. It sounds very much like a paradox.

[pooya87]

Can you help me clarify some of my doubts as stated in the post?

The idea is that if you already have a random entropy you can derive another random entropy from that original entropy by performing certain cryptography functions on it (basically hashing it). For example SHA256 of 32 byte entropy produces a random but deterministic 32 bytes.

Although the algorithm used in RFC6979 is more complicated than that but the principle is the same. You have you private key (which should be random) and the hash of the message that you want to sign (which is not random) and by performing a series of HMACSHA256 you derive a new key.
Since part of the input to HMACSHA was random (the key) the result can not be guessed ergo is random.

The benefit of this is that the algorithm avoids using any kind of RNG that can be weak and since it is deterministic, the ECDSA itself can be easily tested which makes implementing it so much easier.

[Bronsted]

The idea is that if you already have a random entropy you can derive another random entropy from that original entropy by performing certain cryptography functions on it (basically hashing it). For example SHA256 of 32 byte entropy produces a random but deterministic 32 bytes.

Although the algorithm used in RFC6979 is more complicated than that but the principle is the same. You have you private key (which should be random) and the hash of the message that you want to sign (which is not random) and by performing a series of HMACSHA256 you derive a new key.
Since part of the input to HMACSHA was random (the key) the result can not be guessed ergo is random.

The benefit of this is that the algorithm avoids using any kind of RNG that can be weak and since it is deterministic, the ECDSA itself can be easily tested which makes implementing it so much easier.

Understood. I will delve deeper into the topic. Thanks for the speedy response.