# Is this API for ECDSA signature verification consistent with NIST test vectors?

I'm trying to use code from "Easy ECC" package (a github project), for ECDSA-verifying a signature. The problem I'm facing is that the API assumes a public key length of N+1, which is different than NIST test vectors, where the public key is composed of 2 components (Qx, Qy) which are N bytes each. (N is the number of bytes for the chosen derivative. For example, for P-256, N is 32).

To be specific, here is the API (ECC_BYTES is 32):

int ecdsa_verify(const uint8_t p_publicKey[ECC_BYTES+1],
const uint8_t p_hash[ECC_BYTES],
const uint8_t p_signature[ECC_BYTES*2]);


and the corresponding NIST "verify" test vectors are:

P-256,SHA-256
Msg = (omitted)
Qx = e424dc61d4bb3cb7ef4344a7f8957a0c5134e16f7a67c074f82e6e12f49abf3c (32 bytes)
Qy = 970eed7aa2bc48651545949de1dddaf0127e5965ac85d1243d6f60e7dfaee927 (32 bytes)
R = bf96b99aa49c705c910be33142017c642ff540c76349b9dab72f981fd9347f4f (32 bytes)
S = 17c55095819089c2e03b9cd415abdf12444e323075d98f31920b9e0f57ec871c (32 bytes)
Result = P (0 )


R and S are 32 bytes each and this is consistent with the API signature length of 2*N = 64 bytes. Qx and Qy are also 32 bytes each and this is not consistent with the API's public key length of N+1 (33 bytes)

My question is: Does this API conform to ECDSA standard ? Eventually, I will have to test it with test vectors like the NIST one above.

Public keys in this system are very sparse: for any $$x$$ value there are at most two possible $$y$$ values satisfying $$y^2 = x^3 + ax + b$$ where $$a$$ and $$b$$ are the curve parameters, since the equation is quadratic in $$y$$. (And $$x^3 + ax + b$$ has a square root at all only for some values of $$x$$; by Hasse's theorem, the number of points on the curve can't be very far from the number of elements in the coordinate field, so only about half of the possible $$x$$ values work.)
The signature API you're using presumably deals only in compressed public keys, which have maybe some formatting metadata and likely a single bit determining $$y$$ in one byte, together with 32 bytes to determine $$x$$. For example, in the ANSI X9.62 format, the first byte is 0x02 for an even $$y$$ value, or 0x03 for an odd $$y$$ value; then the remaining 32 bytes encode $$x$$.