Why does deterministic ECDSA (per RFC 6979) include the private key in the generation of k?

Question

It's clear that using the private ECDSA key $x$ as an additional input into the hash algorithm, as specified in RFC 6979, doesn't harm security (assuming HMAC_DRBG is a PRF).

But is it necessary?

Would there be any problem with allowing the signature algorithm to have the same output of $k$ for the same message regardless of the key used? Per Is it safe to reuse a ECDSA nonce for two signatures if the public keys are different?, it seems like this should be fine.

If key dependency is indeed the goal here, why is the private key used, and not the public key?

Using the public key, or removing any key dependence entirely, would seem to allow verifying whether a given implementation is using deterministic signatures, which seems like a desirable property in some contexts. For example, it would allow detecting whether a given implementation uses deterministic signatures without knowledge of the private key by observing one or more signatures.

Am I missing something?

Answer 1

But is it necessary?

What is necessary is that someone else could not guess what $k$ was; after all, if they guessed that, they could recover the private key from the signature with a bit of simple algebra.

If they used only public information (the public key and the message), well, the attacker could compute $k$ himself, and that'd be bad.

Of course, you don't have to use the private key specifically; you could use another secret value. However, it is important that you use some secret value (and reusing the private key has the advantage that we only need to keep one thing secret).