Is it OK to use r-value from ECDSA signature (r, s) to prevent replay attack?

Question

ECDSA signatures are malleable. Given a valid signature (r, s), one can create a second valid signature by negating the s value.

I have searched workaround for this issue, and https://yondon.blog/2019/01/01/how-not-to-use-ecdsa says:

One solution to defend against signature malleability based attacks is to enforce a single canonical signature for a given public key and hash which is the approach taken by Bitcoin. More specifically, the Bitcoin core client software will only accept “low s-value” ECDSA signatures where a signature has a low s-value if s is less or equal to half the curve order [3]. The secp256k1 curve library used by the client will always generate signatures in low s-value form and the verifier expects provided signatures to also be in low s-value form [4].

Another solution is to avoid using signatures in identifiers or at the very least making sure to use unique values in the identifier creation process i.e. a nonce in the signed message. Unless there is a single canonical signature for a given public key and hash, signatures cannot be relied upon as unique identifiers.

What I wonder is, is it okay to use r-value instead of s-value for replay detection? One the first thought one should use s-value, because it is derived from a given message. r-value is not derived from a given message, but it uses k-value, which should be a random value. If duplicated k-values are used with same private key the key can be leaked, so signer have to generate distinct k-values. This makes me think r-value can be used to prevent replay attack.

Is there any problem if I use r-value to prevent replay attack?

Answer 1

I have to be honest and say that I never really understood why systems use the signature as the record rather than just the hash of the message that was signed. If that was used, then there would be no problem with using malleable signatures. If someone has a reason why not to just do what I said, please let me know and I'll change the answer.

More to the point of the question, there is no reason why not to just use the $r$ portion. If this repeats in two different valid signatures, then the signers can each learn the other party's private key. This is because by dividing the $s$ portions in the signatures, the $k^{-1}$ part falls away. Then, given one of the private keys it is easy to learn the other private key. As such, this should not be a concern to anyone (i.e., if it could happen then malleability is far from the problem).

Answer 2

There's one potential problem that I can foresee. If two users generate the same ephemeral $r$ and $k$ values (or $\ell -k$), an $r$-only scheme would flag these up as a replay even thought they are not. There should be a negligible chance of this happening, but given a common signature implementation with less than perfect random number generation and a large community of users it could happen, even if individual users take care never to repeat ephemeral values. This would also flag up to the two parties that they can each recover the others private key. Collisions between two different signing keys using $(r,s)$-replay detection should only be possible if the second signing key is specifically generated by someone in possession of the first signing key.