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:

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.


1 Answer 1


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$.

  • $\begingroup$ Given that the compressed and uncompressed formats of the public key are just different representations of the same thing, I can use the API for my purposes. It's also worth to mention sec1v2.0, which has so much information - and is free. $\endgroup$
    – alonco
    Oct 28, 2019 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.