Sorry for the delay, I misplaced this temporarily.
> From: owner-openssl-us...@openssl.org On Behalf Of Odomae Bro
> Sent: Thursday, 08 December, 2011 12:02
> <snip> I am now working with 1.0.0.e and am able to get the
> anonymous DH going. There is only one small problem.
> We use the p and g from the client/server exchange, but the
I hope you mean ServerKeyExchange (only). The ephemeral *keys*
go both directions, but parameters go server->client only.
> DH private(say a) and public i.e. (A = g exp a mod p) is offloaded
> and obtained from our hardware module. Once I get the keys, I copy
> them into the dh_clnt->pub_key and dh_srvr_>pub_key in d1_clnt.c
> and d1_srvr.c respectively.
Okay, that wasn't at all clear from your earlier question (or subject).
And I don't understand the motivation: HSM is normally used to protect
private (and secret) keys. Having it generate DH private+public and
export both (to software) doesn't make sense to me; having it export
only public (for you to send to peer) and then internally do the
agreement (*using* peer public you received) would make sense.
Be that as it may ...
> The way I update the dh_*->pub_key is this:
> DH_compute_key(...) // openssl call
> .....
> //obtain parameters from hardware
> //then copy key into openssl structure for it to be exchanged
> dh_clnt->pub_key = BN_bin2bn(pub_key_buff, modulus_len,
dh_clnt->pub_key);
> If I do this, the exchange stops after the GET_FINISHED_A. If I
> remove the above line, the exchange completes and the client/server exit
gracefully.
I assume that's (your changed) d1_clnt.c.
Ephemeral DH varies from the usual crypto key management model.
DH_generate_key generates a nonce keypair (x=random y=g^x mod p)
and DH_compute_key does the agreement (z=my_x ^ peer_y mod p),
and for ephemeral both of these are done for each handshake.
If you want to do (only) DH key generation in hardware,
replace DH_generate_key call and leave DH_compute_key alone.
In client, using one key's private to compute the key-agreement
then sending a different key's public to the server to use
is effectively guaranteed to cause key agreement to go wrong
-- which is detected when Finished doesn't verify, and should
have given you an error in the server (for a full handshake)
and an alert to the client; did you check for and report those?
And you don't mention the private half at all; using public
half of a DH keypair without private half can't ever work.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
