>From: owner-openssl-us...@openssl.org On Behalf Of Matt Caswell
>Sent: Monday, 18 March, 2013 09:17
>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.
And I would advise against doing so, because generating parameters
is costly. But see below about q.
>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.
This isn't clear. Each side chooses keys (x,y) using the parameters,
which as you say must be the same. With parameters the same, the
*key* values if chosen properly (randomly) will be different.
If the parameters are (wrongly) different, the key values will
overwhelmingly be chosen different also, but even if they are
accidentally the same or x is forced the same, exchange doesn't
work. And see next about q.
>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.
No. *DSA* uses p,q,g. DH requires p,g which effectively determines
q, but DH computation doesn't use q and standard formats don't have
it. DH can use l which is the *size* of q thus the (max) entropy
of the agreement. It is sometimes convenient to use DSA parameters
as DH parameters by ignoring q except optionally its size.
And possibly relevant here, the standard Suncle JCE provider actually
uses DSA paramgen for DH and thus imposes the DSA size restrictions
on DH -- 512 to 1024 in steps of 64 -- although they aren't required
by any standard I know of. I don't recall if JCE also restricts
*existing* (received) params; I'll test when I have some time.
I do recall you can get around this by using BouncyCastle instead.
But just using 1024 is easy and fine.
>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.
Or 2412 (Oakley) or others. There are actually two issues here:
- you don't need to *generate* new parameters every time. If you do,
you must send them. Sending in standard X509-ki format is often
the easiest way (and JCE does by default) but not the only way.
- if you reuse parameters, you don't *need* to send them, but it
can be useful if you do because both parties can check they agree
and something hasn't gotten misconfigured or out of sync.
>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 <snip>
I would suggest configured rather than hard-coded -- but the
important point is fixed/static/long-term versus new each time.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
