On 18 March 2013 12:15, azhar jodatti <azhar...@gmail.com> wrote: > 2) Is this sample from the *same* key exchange? The parameters are > different which are obviously going to cause it to fail. > When I run both programs it calculates the params (p,g,pk) every time on > execution . that's the reason both key values are different. That won't > make any such difference :) right? >
The parameters p, q and g need to be the same on both sides of the exchange. The values for this can be agreed in advance. You do not need to calculate them every time. If the two parties in the exchange are using different parameters then it will not work. Each side will have different private keys, and hence different public keys. . p,q and g are same at both the end. let me tell how i am doing. I am generating p,g and q at client. then I am generating private and public key with these params. I am sending these p,g,q and public key to server and hence server using same p,g and q to generate its private and public key. server generates secret key with client public key and returns its public key. client in turn use the server public key to generated its secret key. I am generating parameter when user logs in and stays till user logout. next time when he logs in the same procedure will happen. You *can* generate the parameters every time - it will work as long as both sides are using the same p, q and g values - but there is no reason to do so I don't think i understood you completely here. but I am ok by generating parameters every time as long as it works :) I also just noticed that in your JSON sample there is only one prime number provided. There are in fact two required: p and q. well, I think other prime number is g and not q. other prime number is base generator i.e g in above JSON sample. > > 3) Its not actually necessary to pass the full parameters every time you > exchange keys. This can be agreed up front, e.g. RF5114 defines a set of > standard well known parameters which can be used "off the shelf". OpenSSL > has built-in support for these. > I need to look into this. Do you mean the hard coded prime and base > generator numbers at client and server? how about public key? > The values p, q and g can be hard coded at client and server. The private/public keys can also be static on both sides of the exchange - but if you do so then bear in mind that the agreed on secret will be the same every time. More likely you will want to use ephemeral mode - one side (usually the server) can have a static private/public key, whilst the client will use a new one every time. This will ensure that a new secret is agreed each time. Yes, I would love to see at least this working. I will try this today, however I still prefer dynamic values over static. :) ;) One other point to make here is that it looks very much like you are designing your own protocol rather than implementing a well defined one. This is fraught with security risks....it is very easy to make a mistake - and is generally a bad idea. Use standardised approaches where ever possible. In particular note that the diffie-hellman implementation in use here provides a "raw" shared secret at the end. Standardised protocols normally define a process for turning that shared secret into something which can be used as a key (typically by passing the secret, along with other data through some message digest). E.g. see RFC 2631 I don't feel i am trying to design my own protocol. at least it won't look so for me :) I want to use symmetric key encryption and for that I need a same secret key at both the ends at run time. Who else does this better than Diffie Hellman? :) :) Matt
