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. 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 also just noticed that in your JSON sample there is only one prime number provided. There are in fact two required: p and q. > > 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. 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 Matt
