Consider and client server scenario and you got two options:
Which one is more secure way? also if public key will come from store say from Client CA store? would it be more secure instead of binding it in Client app?
The deployment will be done via an installer, verifying the version on each run.
With (only) DH key exchange, the client has no way to know that it is really the server he is talking to.
So the conversation would be secure from eavesdroppers, but someone could pretend to be the server and compromise the client.
An embedded key can be replaced. Generally speaking, if the client's machine is not secured by non-software means, you cannot prevent hacking of your client by a sufficiently motivated attacker. Even a TPM is no panacea. The question becomes one of trade-off: attackers' man-hours vs. utility (profit, fame &c) gained. The only really secure way to license a program which does computations is to perform all licensable computations on a server you physically control; https or SSL can be made sufficiently secure by choosing appropriate key lengths, hashing schemes, ciphers &c (a subject of which I know little).
The principle here is actually rather simple: you need to engineer a situation in which it will be in your clients' best interests to protect their passwords/license keys/data/whatever. E.g. if you have a computation server and charge your clients for server time, client keys are proxies to owners' bank accounts.
Don't.
If you need to solve this kind of problem in production code, have an expert do it. There are so many subtle pitfalls in cryptography that chances are you will come a cropper.
As Tobias mentioned above it is better if you don't roll your own protocol. I would suggest to use an implementation of TLS, or at least model your protocol on TLS. TLS provides options for both Diffie-Hellman and Certificate based key exchange.
Take a look at: http://en.wikipedia.org/wiki/Secure_Sockets_Layer
With the public key scenario the client must be generating the key, there is no way you can have any confidence this key is securely generated (someone could get access to the system and change the key generator to always use the same value, increment the previous value by one, whatever, said attacker can then eves drop on your communications for ever more). Public key crypto was not designed for this purpose.
Diffie-Hellman would be better but as Tobias said if you roll your own you'll probably leave an attack.
Well private key algorithms usually offers better performances (by an order of magnitude or more as far as I can remember) then their public key counterpart. In that sense Diffie-Hellman would be more efficient then say RSA for a client-server architecture.
If you have far far more clients then servers, you could implement a public-key algorithm to reduce the exchanges between them.
Still, like many people said, you should consider asking/hiring an expert on the matter as there is many different types of attacks (most of them targeting only the implementation and not the algorithm per se). If you still want to proceed, I can only wish you best of luck and point you to this resources you should very carefully read.
Can diffie hellman be executed between 3 parties.... Bob alice and eve????