1

Suppose in a network, the identity of users is their public key, which is generated based on the ECDSA algorithm. That is, to create a valid identity, a user must generate an ECDSA public key and then send it to the network administrator for validation. Then, the network administrator needs to know if the user followed all the ECDSA key generation steps correctly to ensure that the user's public key is a valid ECDSA public key.

The question is if the administrator is able to do this confirmation? and how to do it?

I propose here my solution, although I am not sure if the approach is Ok.

Assume a user generates a fake public key claiming it is generated according to the ECDSA algorithm. He must send the key to the network administrator for verification.

The committee then to verify the key sends a text to the user and requests him to sign in. After receiving the signed text verifies the signature using the user's public key. If the result of signature verification is true, it means that the public key is a correct public key, otherwise the user's public key is rejected as an invalid public key which is not generated based on the ECDSA algorithm.

Questioner
  • 211
  • 1
  • 8

1 Answers1

2

to create a valid identity, a user must generate an ECDSA public key and then send it to the network administrator for validation

That's under-specified, lacking:

With this, there is a well-defined process to verify that the public key is valid. First check that it is per the specified format, and peel that as necessary to perform Validation of Elliptic Curve Public Key, and within this the Elliptic Curve Public Key Validation Primitive (notice that depending on the public key format, it might be necessary to first perform point decompression as in Octet-String-to-Elliptic-Curve-Point Conversion).

Update: A common public key format in bitcoin (after 0.6) is the raw compressed public-key format for the implicitly specified curve secp256k1. A validity check of that boils down to:

  • Check that the public key is exactly 33 bytes.

  • Check that its first byte is 02h or 03h (this byte codes the parity of the $y$ coordinate, and needs no further check).

  • Convert the remaining 32 bytes to integer $x$ per big-endian binary convention, which implies $0\le x<2^{256}$.

  • Check that $x<p$, where $p$ is the prime $2^{256}-2^{32}-977$.

  • Compute $s\gets(x^3+7)\bmod p\,$

  • Check that $s^{(p-1)/2}\bmod p\,=\,1$. Per Euler's criterion, this verifies that there exists integer solutions $y$ to the curve's equation $y^2\equiv x^3+7\pmod p\,$. On curves with cofactor $h=1$, including secp256k1, this proves there exists a matching private key.

    Note: Sometime we need the Cartesian coordinates of the curve point defined by the public key. Since $p\equiv 3\pmod 4$ for secp256k1, that can be done efficiently together with a slightly modified version of the above last step:

    • Compute $y\gets s^{(p+1)/4}\bmod p\,$.
    • Check that $y^2\bmod p\,=\,s$, which completes the check.
    • If the low order bit of $y$ does not match the low order bit of the first byte of the public key, then change $y$ to $p-y\,$. Now $(x,y)$ are the desired Cartesian coordinates, with both $x$ and $y$ in $[1,p)$.

The above tells how to check that the public key is valid, but not that the user (or anyone) knows the corresponding private key. This is best done after validation of the public key (in the above sense), then by the challenge/response method in the question.

Checking that the user knows the corresponding private key has one advantage: if the "text to the user" is unique to each key validation, and can't be confused with other messages that the key will sign, then this prevents a user from registering the preexisting public key of another person (which private key is secret).

fgrieu
  • 149,326
  • 13
  • 324
  • 622