Yes I realise I can be open to a 'man in the middle' attack but I'm not bothered about that at the moment - just getting crypto++ to work! See the text below for some earlier correspondence with someone who didn't reply to the list (sigh!)...
Right, thanks for clearing that up. I thought DH was just for key/entropy/bit-source agreement. But that still leaves me to transfer something over the wire. Once the client and server have generated their separate public-private pairs as in: <snip> // Setup the pseudo random number generator AutoSeededRandomPool *arng = new AutoSeededRandomPool; RandomNumberGenerator &rng = *dynamic_cast<RandomNumberGenerator *> (arng); // declare a diffie-hellman object DH dh (rng, 128); // declare the local validation and public-private key pair SecByteBlock local_validate (dh.AgreedValueLength ()); SecByteBlock local_public_key (dh.PublicKeyLength ()); SecByteBlock local_private_key (dh.PrivateKeyLength ()); // clear the validation object fill (local_validate.begin (), local_validate.end (), 0x10); // generate the public-private key pair dh.GeneratePrivateKey (rng, local_private_key); dh.GeneratePublicKey (rng, local_private_key, local_public_key); delete arng; </snip> do they exchange their public keys and then call dh.Agree() individually? If this succeeds then I can produce either a SHA1 or MD5 hash of it yes? You have helped clear my understanding of DH thanks. But it still leaves some API questions. Along with the above why the following: lines 198 and 199 validat2.cpp: memset(val1.begin(), 0x10, val1.size()); memset(val2.begin(), 0x11, val2.size()); Why 0x10 and 0x11 in particular? Can these be any values - do they have to be different? Do I have to do it at all!? Finally (sorry) can someone confirm if I have transferred the keys over the sockets in the correct manner!? Using StringSource and StringSink and HexEncoder? Thanks again for your time. Regards Jim On Wed, 2004-02-18 at 17:23, The Purple Streak, Hilarie Orman wrote: > DH is not a public key encryption method, it is a public-key key > exchange mechanism. Thus, DH is only the first step. After > completing it, the two parties have agreed on a shared block of bits. > Now they need a symmetric encryption algorithm and a way to turn the > block of bits into a key for that algorithm. A typical solution would > be use AES for encryption and the first 128 bits of SHA1 (of the DH > value) for the key. > > Hilarie On Thu, 2004-02-19 at 07:54, Iain Walmsley wrote: > You realise of course that encrypted traffic between unvalidated hosts gives > you no guarantee of security as you cannot claim to be certain as to who you > are encrypting the traffic for? If you do not validate the hosts at all, > you cannot guarantee the security of the public key which is transfered over > an open network. Ie if Im trying to establish a secure channel with machine > B and I recieve a public key, I cannot be sure this key is A) even from B in > the first place, or that only myself and B know the key. > > Iain -- James Vanns BSc (Hons) MCP Linux Systems Administrator Senior Software Engineer (Linux / C & C++) Canterbury Christ Church University College Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x24045370
