> Sent: Monday, 17 December, 2012 08:26
> To:
openss...@openssl.org
> Subject: Re: Need help in loading private key for ECDSA
>
> Thanks for ur help .
>
>
> Can you guide me how can I use ECDH for exachnaging of the
> secret key.
> I have to implement in two phases.
> 1.i have private key of 256 bit lenght need to get phase i1
> value wx,wy
> 2.In second I have phase1 value and private key and need to get secret
> key or public key.
>
If you are using a 224-bit curve, as in your previous posts,
a privatekey larger than 224-bits (really, larger than the field
order, which is fractionally less) is at best a waste of time.
The point_mul probably does work -- I haven't tested -- but if so
it wraps around and gives no more security than a 224-bit value.
For ECDH agreement, like DH, you need to do two phases at both parties.
A has or chooses A-privatekey which determines A-publickey and sends
A-pub to B; B similarly has or chooses B-priv and sends B-pub to A.
A uses B-pub with A-priv to compute a resulting secret and B uses
A-pub with B-priv to compute the same (shared) secret. The only real
difference is that DH pubkey is one number in Z_p while ECDH
pubkey is a nominally 2-dimensional point in the EC group.
If you somehow have a secure privkey but not the corresponding pubkey,
do what the last lines of EC_generate_key do: multiply (in the group)
the base point by your privkey to get your pubkey. To do "phase 2",
use EC_compute_key which multiplies the *peer* pubkey (point) by
your privkey and takes the x coordinate as the agreed value.
Note if both parties have fixed keys -- called static [EC]DH or more
specifically both-static or static-static -- the resulting agreed value
is always the same. If you allow this, you must ensure the agreed value
is used in a way that does not reduce security or allow attacks. Often
this means not using it directly as a key. (TLS always mixes per-connection
client and server nonces into its key derivation, for all key-exchange
methods including both static and ephemeral/anonymous *DH.) If you force
at least one party to use dynamic/nonce/transient/ephemeral key, with
sufficient randomness/entropy in its key, that avoids this issue.