It's in the EC_GROUP structure: group->field. Check crypto/ec/ec_lcl.h. BBB
On Thu, Dec 19, 2013 at 9:54 AM, Patrick McCorry <stonecold...@gmail.com> wrote: > Thank you Billy for the clarification - is there a way to retrieve the value > for "p" that is used under the hood? I assume the p value does not change > (unless the curve is changed). > > Sent from my iPhone > >> On 19 Dec 2013, at 17:35, Billy Brumley <bbrum...@gmail.com> wrote: >> >> http://en.wikipedia.org/wiki/Elliptic_Curve_DSA >> >> "order" in the code you pasted = "n" in the wiki = "N" in your mail. >> >> The code you pasted refers to GFp so the points (x,y) satisfy 0 <= x < >> p and 0 <= y < p. That's probably what you mean by "q". Anyway, it's >> used in the underlying elliptic curve operations but is not >> necessarily needed at the ECDSA level -- all that needs is the outputs >> from scalar multiplication (i.e., p is used under the hood in >> EC_POINT_mul and EC_POINT_get_affine_coordinates_GFp). >> >> BBB >> >> >>> On Thu, Dec 19, 2013 at 2:52 AM, Paddy <stonecold...@gmail.com> wrote: >>> Hi, >>> >>>> From my understanding ECDSA has a modulus N and a field size of q. >>> >>> When generating the co-ordinates (x,y) using the generator and random value >>> k - g * k = (x,y) - the x and y values should be restricted to the range x = >>> [1, ... , q-1] and y = [1, ... , q -1]. >>> >>> Then of course to get r we do: >>> >>> r = x mod N >>> >>>> From what I can see in the implementation (ecs_ossl.c) when using >>> ecdsa_sign_setup - the 'q' field size is never used! >>> >>> /* >>> * Does the multiplciation of G (generator) * k to produce curve point (x,y) >>> */ >>> EC_POINT_mul(group, temp_point, k, NULL, NULL, ctx) >>> >>> /* >>> * Retrieve BIGNUM for X value (don't need y) >>> */ >>> if (EC_METHOD_get_field_type(EC_GROUP_method_of(group)) == >>> NID_X9_62_prime_field) >>> { >>> if (!EC_POINT_get_affine_coordinates_GFp(group, >>> tmp_point, X, NULL, ctx)) >>> { >>> ECDSAerr(ECDSA_F_ECDSA_SIGN_SETUP,ERR_R_EC_LIB); >>> goto err; >>> } >>> } >>> >>> /* >>> * Get r value by doing r = x mod N >>> */ >>> if (!BN_nnmod(r, X, order, ctx)) >>> { >>> ECDSAerr(ECDSA_F_ECDSA_SIGN_SETUP, ERR_R_BN_LIB); >>> goto err; >>> } >>> >>> As well, in the verification of a signature 'q' should be used - but from >>> the implementation in the do_verify method, when 'mod q' should be executed >>> - it is actually doing it on the order N: >>> >>> /* u1 = m * tmp mod order */ >>> if (!BN_mod_mul(u1, m, u2, order, ctx)) >>> { >>> ECDSAerr(ECDSA_F_ECDSA_DO_VERIFY, ERR_R_BN_LIB); >>> goto err; >>> } >>> >>> /* u2 = r * w mod q */ >>> if (!BN_mod_mul(u2, sig->r, u2, order, ctx)) >>> { >>> ECDSAerr(ECDSA_F_ECDSA_DO_VERIFY, ERR_R_BN_LIB); >>> goto err; >>> } >>> >>> -------------------- >>> >>> To sum up - when does the field size 'q' get used (as depicted in the >>> algorithm description)? As it makes the r = x mod N operation pointless? >>> >>> >>> >>> -- >>> View this message in context: >>> http://openssl.6102.n7.nabble.com/ECDSA-OpenSSL-Implementation-using-the-modulus-N-instead-of-field-size-q-tp47743.html >>> Sent from the OpenSSL - User mailing list archive at Nabble.com. >>> ______________________________________________________________________ >>> OpenSSL Project http://www.openssl.org >>> User Support Mailing List openssl-users@openssl.org >>> Automated List Manager majord...@openssl.org >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
