I\'m testing an implementation of Bitcoin, which uses the curve Secp256k1 for EC
ID: 650140 • Letter: I
Question
I'm testing an implementation of Bitcoin, which uses the curve Secp256k1 for ECDSA, and I want to see how it handles the point at infinity (0) if present in a signature. For example, r could be the x coordinate of the encoding of the point at infinity.
How is the 0 encoded? Can it be encoded?
I found that bouncycastle prefixes the encoding of 0 with 0x00, and has some other defined prefixes (ECCurve.decodePoint()) but I don't known how this information applies (or even if it does apply to) to the encoding of (r,s). This info seems to be in the X9.62 standard.
Explanation / Answer
Standard encoding of the point at infinity is a single byte of value 0x00 (it is defined as such as least in P1363, possibly also in X9.62). Other representations may exist (such as a lot of bytes of value 0x00), but, in truth, the "point at infinity" does not have well-defined X and Y coordinates.
In the case of ECDSA, you generate a random value k which must lie between 1 and r-1, where r is the (prime) order of the conventional generator point G. Therefore, kG cannot be the point at infinity -- if it is, then the implementation got it wrong, or the key is not correct. Since kG is not the point at infinity, then it always has a well-defined X coordinate, and the problem does not arise. Similarly, if the point at infinity is obtained during the verification algorithm, then something definitely fishy is happening, and therefore the signature should be rejected (this cannot happen with a valid signature).
The same can be said about elliptic curve Diffie-Hellman. To sum up, if the encoding of the point-at-infinity begins to matter, then something went wrong and the best thing to do is to declare a failure (e.g. reject the signature as invalid).