Re: Deterministic Ways to Generate K for DSA and ECDSA

Hey everyone, I need your thoughts on two methods for generating K: 1. Following RFC 6979. Our worry is that for a given private key and message, we always end up with the same signature, plus we might need to add some extra details about our signatures. 2. Using a secure random source like /dev/urandom, hashing the generated K, and then saving those hashes in a database to prevent any duplicate K issues.

1. That's the whole point of RFC-6979, to generate a deterministic k (same value with same key+msg) There is no additional info being provided with the signature that you produce this way. 2. A simple hash of the produced k using a random number generator won't provide security if that random source is not secure to begin with. Also storing that k in a DB would also add a secondary point of failure since DB could be leaked and that puts your keys in danger. Not to mention that if k is actually random, you should not encounter a collision to need to make sure it is not a duplicate. Also keep in mind that k is called "ephemeral key" for a reason. It is not supposed to be stored.

Thanks for answer, and sorry for my weird English, I try explain my concern as accurate as Google translate helpful in such tricky theme. 1. If we use 6979 we provide the relation between private key and msg to K. So in theory we have two equation with two variable. So we belief that HMAC is strong, and the are no hidden relation between input and output. Other concern that rfc6979(d+k)=a*d+b*g, where g is the base point, and a and b is coeffs easy calculated from s and r from signature. May be HMAC is strong in general, and from my experience it is strong enough, but the issue, that all black box calculations after HMAC has linear result. 2. Why we belief that rfc6979(d+K) stored in blockchain as signature in public access more strong than rfc6979(K) stored in private DB? If we use rfc6979 algorithm as hash function for store K, to avoid double use K problem. Upd: we can store in DB the K point, instead hash. For fast check K duplicate. As K is public we haven't any risk, and store it locally for fast check usage.

Most attacks involving RFC6979 nonces can be thwarted by adding some sort of byte counter after the message before hashing. Like this: HMAC-SHA256(private key + message + (0x01, 0x02, 0x03, or 0x04, and so on...)) It is a simple modification, and quite weak, but most people do not make transactions like that, so hackers will not consider adding extra bytes when they perform this type of attack. The reason is that in a private database could be tampered with by unauthorized people, whereas you can be certain that nobody has touched the rfc6979(d+K) stored in the transaction (the signature section of the transaction).

More understanding if use pubkey as many as possible in rsz formula. k nonce like publick key in range, but not BIP32 seed phrase security level.