Thanks, OK I got the rest of the way through the tangled mess. The question is there someone out there that can skip trace through the subroutines that can put together a tight code set on how this works? One command walk through to start from the beginning to the end which is the key feedback. If there are some good c++ people out there that might want to spend a day on it I can pay for the time.
Dave On 8/7/2014 6:58 PM, Dave Thompson wrote: >> From: owner-openssl-us...@openssl.org On Behalf Of dave >> Sent: Monday, August 04, 2014 15:50 >> I have it that the elliptic multiply is not standard. So I have been >> skip tracing though the code. >> It starts with ec_key.c, with EC_KEY_generate_key. This grabs the >> group or or the particular curves prime field size. It then uses this > No, it uses the order of the generator or equivalently the subgroup > generated by the generator and used for operations. For a curve > over a prime field Zp the subgroup order is either slightly less than p > or slightly less than p divided by a small integer called the cofactor > (small meaning usually 2 or 4). For a curve over a "binary" (m-bit) field > the order is somewhat less than 2^m, or that divided by a small cofactor. > >> as the range for bn_rand_range. This is in bn_rand.c. In that it >> uses the first half which is bnrand. That grabs the time and shifts it >> around to start the process. Since the order or range is a large number > It logically adds the current time (assuming available) to the entropy pool. > Adding entropy is done by mixing bits in a fashion that should depend on > both/all inputs in a complicated way, but I haven't looked recently. Using > *only* the current time to seed random generation would not be secure, > and is a common mistake by inexperienced people. > >> in hex it looks like the output of the private key is also in hex. > The private key is a large (integer) number. There are many ways of > representing integers. Hex is a common way of representing large integers, > because it can easily be broken up into, or formed from, 8-bit bytes or > other > power-of-2 size units that are common on modern computers. In particular > when an EC private key is stored in the standard ASN.1 format defined in > X9.62 > and used in among others PKCS#8 and PKCS#12, the privatekey is stored as > ASN.1 integer which some tools including openssl asn1parse show in hex. > >> After that the generate key does the point multiply to make the public. >> Is there some other variable used here that I am missing? >> > Doesn't sound like it. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
