ECDSA points with x-values between n and p

[vjudeu]

This point seems to be valid, and on secp256k1, as far as I know:

Code:

04 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 98F66641CB0AE1776B463EBDEE3D77FE2658F021DB48E2C8AC7AB4C92F83621E

Also, for those two different points, we reach the same r-value, because point coordinates are calculated modulo "p", but signatures are calculated modulo "n":

Code:

04 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364143 C94E559D14883E68CFDA34341568BF1127153254788DD974C6AF9BB9CD962A5C 
04 0000000000000000000000000000000000000000000000000000000000000002 66FBE727B2BA09E09F5A98D70A5EFCE8424C5FA425BBDA1C511F860657B8535E

Does it mean that when it comes to malleability, there are more cases than (r,s) and (r,-s), and that it is possible to alter it somehow? Or does it mean that for the same message, and the same signature, there is more than one matching public key?

[ymgve2]

Pretty sure any r that's above or equal to FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 is considered invalid by Bitcoin.

Nevermind, I misunderstood. I think technically it might be a malleability, but since I assume you don't know the actual private keys behind any of the public keys, it's more a theoretical issue than practical.

[pooya87]

You can derive more than one possible public key from a valid ECDSA signature and message but that is not related to malleability since the public key is always locked in the script that is being spent one way or another (it is unchangeable).
For example in a P2PKH script the hash of the public key is already locked in the scriptpub and if you use a different public key the transaction will be rejected on OP_EQUALVERIFY before it even reaches the signature verification step.

P.S. All 3 public keys you posted are valid since they are on secp256k1 curve.

[witcher_sense]

This point seems to be valid, and on secp256k1, as far as I know:

Code:

04 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 98F66641CB0AE1776B463EBDEE3D77FE2658F021DB48E2C8AC7AB4C92F83621E

Also, for those two different points, we reach the same r-value, because point coordinates are calculated modulo "p", but signatures are calculated modulo "n":

Code:

04 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364143 C94E559D14883E68CFDA34341568BF1127153254788DD974C6AF9BB9CD962A5C 
04 0000000000000000000000000000000000000000000000000000000000000002 66FBE727B2BA09E09F5A98D70A5EFCE8424C5FA425BBDA1C511F860657B8535E

Does it mean that when it comes to malleability, there are more cases than (r,s) and (r,-s), and that it is possible to alter it somehow? Or does it mean that for the same message, and the same signature, there is more than one matching public key?

According to BIP62, when the value of s is more than half of n (the total number of points), we simply take s = n - s. In other words, given this rule, any signature where the value of s is too high is considered invalid. As for public keys, there can theoretically be 4 different public keys for the same message and private key if the value of r is lower than n-p. In this case, you will have two x-coordinates (x=r and x=r+n) and two y-coordinates for each x (even and odd).

[NotATether]

It is purely an academic discussion, as the probability of hitting any x mod n is already so low that dividing the probability by two won't make much of a difference in terms of security.

[stwenhao]

It is purely an academic discussion

It is not so academic, if you note, that 02FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 and 03FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 is considered as "zero", when used as "r-value". Which means, that instead of "s=(z+rd)/k", when "r=n", then it is simplified to "s=z/k", and then, the signature no longer depends on "d-value", which means, that it can be valid, regardless of the used public key (it depends on the exact implementation, how it is handled, and if that can cause a fork or not, when one node will consider something as valid, while another node will reject it).

Also, it stops being so "academic", if you note, that "Q.x==n" is not the only choice, that can cause some issues. For example, here is another valid key: 027fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0. And another one: 024ccccccccccccccccccccccccccccccc6b34757867c8fcdeb98be92a3e76ad2d. And then, even if all public keys are restricted, to have their (x,y) coordinates strictly below n-value, then there are still some dependencies inside secp256k1, which can lead you to a "weak" signature, if it was based on a "weak" value like that.

Definitely, it is something to be explored on weaker curves than secp256k1, to make sure, that signatures are not too easy to tweak, and that the attacker cannot achieve any advantage, by trying to land on 02FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, 027fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0, or similar points, for different implementations.